pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Whitcomb <RogerandB...@rbwhitcomb.com>
Subject Re: Automated support for enums
Date Tue, 07 Sep 2010 03:26:34 GMT
 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 <cbartlett.x@gmail.com>  
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 <gkbrown@mac.com> 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
>>
>>

Mime
View raw message