(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 <[email protected]> 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 > >
