From what I understand, the problem is determining (by reflection)
what the appropriate enum class should be to call the "valueOf" method
on.
I'd like to have this myself!
~Roger Whitcomb
Sent from my iPhone
On Sep 6, 2010, at 6:13 PM, Chris Bartlett <[email protected]>
wrote:
I'm not sure I fully understand what you are proposing.
Is this to remove the need for methods such as
BoxPane#setOrientation(String orientation)
and just keep
BoxPane#setOrientation(Orientation orientation)
when processing BXML such as
<BoxPane orientation="horizontal"/> ?
If so, then how about first attempting a valueOf using the raw
attribute
value from the BXML? If that fails, then try with the uppercase
ersion.
That would allow case sensitive, mixed case values to be supplied in
BXML.
This could happen the other way around if preferred, and also could
enforce
a toUpperCase() conversion if the enum lived in a Pivot package.
(If that
is the Pivot convention)
Chris
On 7 September 2010 07:24, Greg Brown <[email protected]> wrote:
I was thinking about how we might add support for automatically
converting
strings to enum values, and I came up with something that might
work (though
I have not prototyped it). We might be able to use reflection to
get the
valueOf() method on a particular enum type, and then invoke it with
the
string value. We could potentially do this in BeanAdapter.coerce(),
since
all BXML type coercion ultimately flows through this method.
However, there's one minor issue with the concept. All of our enum
conversion overloads currently call toUpperCase() on the value. We
do this
primarily so we can use lower case values in BXML (for
readability). We'd
have to do the same thing in coerce() in order to eliminate the
overloads.
In general, developers seem to adhere to the all caps/underscore
convention
when naming enum values, but it isn't strictly enforced. We'd
therefore be
imposing a slight limitation on the use of coerce().
I'm on the fence about it. BeanAdapter and BeanMonitor currently
rely on
other naming conventions (getter and setter methods, getXXXListeners
(),
etc.), so it's not that far-fetched. If the reflection approach
works, is
the case conversion a limitation that we can live with?
G
