reducing code for BXML serialisation

[Noel Grandin <no...@gmail.com>]

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

Re: reducing code for BXML serialisation

[Greg Brown <gk...@mac.com>]

> public class Component {
>  public Icon bxmlFromString(String s) {
>    .. decode string URL into Icon here...
>  }
> }
> 
> public class Button extends Component {
>  public void setIcon(Icon icon) {
>  }
> }

OK. I see a couple of issues with this:

1) There's no setIcon(String) method that I can call from Java or another language. I have to use BXML to invoke that setter. That goes against a major Pivot design principle, which is not to make BXML a dependency.

2) The "bxmlFromString(String)" method can only have a single return type. So, we can't apply this as a general conversion solution (for example, if we were to add another version that returned an Orientation, it won't compile).

It also seems too "magicky". The current approach may require some apparent duplication of code, but it is straightforward and does not rely on behind-the-scenes tricks.

The intent is good, though. As I mentioned earlier, if you can figure out a way to generically manipulate enums in BXMLSerializer, we could at least eliminate those setter overloads.

G

Re: reducing code for BXML serialisation

[Noel Grandin <no...@gmail.com>]

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 <gk...@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).
>
>
>

Re: reducing code for BXML serialisation

[Greg Brown <gk...@mac.com>]

> (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).

Re: reducing code for BXML serialisation

[Noel Grandin <no...@gmail.com>]

(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 <gk...@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
>
>

Re: reducing code for BXML serialisation

[Greg Brown <gk...@mac.com>]

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