Joseph Kesselman wrote: > But, as you note, this value is not a boolean value. It's tristate. By > switching to Boolean you're already taking a step away from that simple > view.
I don't think it's a step away. In my work writing other parser configurations, I've found that I need a method like this for my components. It makes it a lot easier to mix and match components among various configurations without requiring the configuration to somehow know what default values to use for settings recognized by the various components. For what this method (getFeatureDefault) is intended for, you actually need a tristate value: true, false, and null. So I think the Boolean object is the natural choice. *And* when the component wants to supply a default value, it maps nicely back to the primitive boolean. I think changing this to any other enumeration, whether it be ints or some enum class is a bad idea. > If you really want to stick with booleans it could be done by > "piggybacking" two features, so you've got two bits to work with. I don't think this is a good idea -- look at the whole "namespaces/namespace-prefixes" confusion for an example. And besides... this does me no good for what this method is designed to do, which is to return a preferred default state for a feature recognized by that component. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
