pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noel Grandin <noelgran...@gmail.com>
Subject Re: reducing code for BXML serialisation
Date Sat, 04 Sep 2010 12:42:32 GMT
(1) Yeah, that's why I said to put the decoding methods into the
destination object. That way this kind of decoding can be used by
anyone.
(2) Enum require specialised handling because some of the methods on
them are generated by the compiler, so they require some finicky
reflection, but it's certainly doable (basically requires using
reflection to call valueOf on the correct enum subclass)


On Sat, Sep 4, 2010 at 13:49, Greg Brown <gkbrown@mac.com> wrote:
> It is an interesting idea, but BXMLSerializer isn't the only client of these methods.
Also, I tried to add enum support to BXMLSerializer at one point but couldn't get it to work
(if I recall correctly, I wasn't able to use reflection to dynamically create enums of the
appropriate type).
>
> On Sep 4, 2010, at 7:09 AM, Noel Grandin wrote:
>
>> Hi
>>
>> I note that we have lots of methods of the form
>>
>> public void setFoo(String s)  {
>>  .. decode s and call setFoo(FooEnum)
>> }
>> public void setFoo(FooEnum e) {
>> }
>>
>> And most of the time, the decoding process is identical for all of the
>> methods that take a given argument type.
>>
>> I suggest that we teach BXMLSerialiser to look for methods of the form
>>
>> public String bxmlFromString(T arg)
>>
>> on the destination object, which it will use to decode the argument
>> from a string, and then call the real setter.
>>
>> That should allow us to remove virtually all of our extra setFoo()
>> methods into an appropriate superclass (like Component).
>>
>> -- Noel
>
>

Mime
View raw message