> There is, let say "address" is a Boolean Boolean -> Boolean is a nonsense coercion, the typecoercer actually checks if the type is assignable from the source type and returns the input unchanged.
These: Long --> Boolean String --> Boolean Already exist. Since they are a better match than Object -> Boolean they are chosen, when the types are String/Integer. There are side effects. Anything that could previously gone from XYZ -> String -> Boolean would now instead use Object -> Boolean and the semantics would change. For instance, if XYZ.toString() returns "true"/"false" it would now always be true, unless it was null. Or more realistically, if you go from MyObject -> Long -> Boolean (think entity) the MyObject would be false if MyObject -> Long results in 0, which may or may not be your intention. Integer currently goes through Number -> Long before Long -> Boolean, making Object -> Boolean a preferred match. Changing Long -> Boolean to Number -> Boolean could resolve that. The TypeCoercer keeps a cache of all the coercion paths that it's created. It would be nice to expose that via a page or JMX call so that we can understand what magic is happening for us. For instance, I too have complex objects going to String before Boolean and didn't know it. > Do you agree now that it should be added? Definitely. I'd rather add the Object -> Boolean and appropriate other coercions instead of adding a feature to the property expressions. I'm adding them to my personal project now. I'll be happy to add them to the framework once the dust of this thread settles :) Josh On Wed, Aug 24, 2011 at 10:34 AM, Denis Stepanov <denis.stepa...@gmail.com> wrote: >> Is there any reason for Tapestry-IoC or Tapestry-core themselves not >> providing a direct Object -> Boolean coercion? > > There is, let say "address" is a Boolean then you can't check for null, > because if it is null it will return false and if it isn't could be false too. > It will not work for default coercions Object -> Boolean: String, Long, > Collection... > > Do you agree now that it should be added? > > Thanks, > Denis > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
