Re: [equinox-dev] boolean properties etc

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

For the backwards compatibility case,
yes, we could just add additional values for existing headers/properties.
 There are a couple issues that may crop up.
- From an API point of veiw, if we spec'd
that the property was true/false then people may well have written code
of the form
        if
(prop==true)
         
      do stuff
        else
         
      do other stuff
That is, the false case is not explicitly
captured.  

- Some of this directiion is to help
increase understandability.  For example, adding "jar" and
"directory" to the set of values for the feature "unpack"
attribute does not flow well.

In any event, for backward compatibility
you can add support for the new header/property and leave the support for
the old.

Note also that I am not proposing that
we agressively change existing headers/properties but rather take into
account these characteristics when adding keys (and perhaps values)

Jeff

David M Williams <david_williams@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/28/2006 11: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