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 13:37:52 GMT
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 <gkbrown@mac.com> 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).
>
>
>

Mime
View raw message