This is an example
public class Component {
public Icon bxmlFromString(String s) {
.. decode string URL into Icon here...
}
}
public class Button extends Component {
public void setIcon(Icon icon) {
}
}
Note that Button no longer needs a setIcon(String) method, because the
conversion is done by the superclass method.
I'm not suggesting that we do this for all cases.
The default would still be to call a setFoo(String) method, if such a
method existed.
This would be the next option for BXMLSerialiser to try.
The upside is that it could remove a great deal of duplication from
the existing code, without having to add lots of conversion logic into
BXMLSerialiser itself.
On Sat, Sep 4, 2010 at 14:50, Greg Brown <[email protected]> wrote:
>> (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.
>
> Right, but, as a caller, setFoo() makes more sense to me than
> bxmlFromString(). But maybe I misunderstand the intent. It might help to see
> a practical example.
>
>> (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)
>
> I couldn't get it to work, but maybe you can.
>
> I'm definitely not opposed to adding enum support directly to BXMLSerializer
> if it is possible, but I'm not convinced that we can (or want to) get away
> from setter overloads altogether (for other types).
>
>
>
