Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] boolean properties etc


Yup, this is the direction I was thinking.    David Williams, in another message, suggested that it might make sense to have a "default" value as well.   That captures the case where the user really explicitly said that they wanted the default rather then saying nothing at all.  The distinction is subtle but in somecase it may be interesting.

Jeff



Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/29/2006 08:20 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] boolean properties etc






We are in the process of proposing a lazy-start mechanism for the next release of OSGi.  When/If this gets added to the OSGi specification the Eclipse-LazyStart header will not be used.  Currently we are thinking of adding a Bundle-StartPolicy header.  To start with we will only specify a "lazy" policy but this leave us open to other types of "start policies".  Jeff, is this a more acceptable approach for the header and its values?


For more details on the lazy-start policy being proposed to OSGi see http://bundles.osgi.org/Design/LazyStart


Tom




David M Williams/Raleigh/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/28/2006 10:40 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] boolean properties etc








Makes sense to me.

Another possible advantage of enumerated attribute values is that there might be some cases where 'systemDefault' would be a good option,
so that some "meta data" could specify "use form=jar/dir unless otherwise specified".
I don't know if that particular example is valid, or how many cases this would be needed or make sense ... so, take with a grain of salt.
But, I've actually seen this anti-pattern? a lot with "user preferences" ... the intial tendancy is often to think of some user preference as "on or off" but 50% of the time
the next release reveals more cases ... "not specified by user" being an obvious third choice.

But, for manifests, couldn't "true/false" usually be deprecated, and future versions be spec'd as multivalued (and 'true', 'false' be assigned to one of the new states, for backward

compatibility?). But I do agree, its just more meaningful to spec what you mean :)






Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/28/2006 11:11 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
equinox-dev@xxxxxxxxxxx
cc
Subject
[equinox-dev] boolean properties etc










There have been several cases lately where we are being burned by having used boolean values for properties, headers, ...  In particular, things like
     unpack=true/false

     Eclipse-LazyStart: true/false

are problematic for a few reasons.  


- First we seem to have this tendency to specify them in the negative.  For example unpack=false is the default way we want things.  That approach made sense in the context of the day but today it is just hard to deal with the double negative.  


- It is not always clear what the property is controlling.  unpack, for example, is somewhat cryptic.


- Perhaps the most interesting issue relates to extensibility.  Eclipse-LazyStart: true/false has only two possible values.  Recently there has been some discussion about adding an eager mode.  Ignoring the details of that request and assuming we did want this, with only true and false for Lazy start, we would have to add another header for eager mode.


An alternative would be to avoid headers, arguments, properties etc that have boolean values.  Instead of unpack = true/false, use something like form=jar/dir.  Eclipse-LazyStart would be something like Eclipse-BundleStart: lazy/manual/eager.  This approach is more extensible and seems easier to usnderstand. Note also that these headers can have additional information provided as attributes or directives in the standard OSGi manner.


Thoughts

Jeff


p.s., note that this thinking should also be applied to any OSGi RFCs we put forward.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top