pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: WTKXSerializer#bind
Date Tue, 03 Nov 2009 22:10:09 GMT
How about adding a single arg version which just calls the multi-arg
one doing a .getClass() and passing that in?

The only problem with that being that the parameterization would have
to be removed from the multi-arg version as it wouldn't be able to
resolve the generics properly, though I don't see what value that is
adding anyway.

It would end up looking like this and should still be source compatible:

>    public void bind(Object o) throws BindException {
>        bind(o, o.getClass());
>    }
>    public void bind(Object t, Class<?> type) throws BindException {
>        Field[] fields = type.getDeclaredFields();


2009/11/3 Greg Brown <gkbrown@mac.com>:
> We have tended to favor simplicity when it is not at the expense of
> flexibility in Pivot, and the one-arg signature is simpler (i.e. clearer).
> Todd, is it possible to refactor your code to use composition as Chris
> describes?
> On Nov 3, 2009, at 4:55 PM, Christopher Brind wrote:
>> I figured it would be something like that, though using a complex
>> hierarchy (even more than one or two classes deep) goes against my
>> usual practice of using composition over inheritance where possible,
>> this the multi-argument signature isn't something I'm likely to
>> benefit from.
>> It's a minor inconvenience, but that's all.  Just curious. :)
>> Cheers,
>> Chris
>> 2009/11/3 Greg Brown <gkbrown@mac.com>:
>>> Oh, now I remember. We didn't like the fact that subclasses could modify
>>> private members of their base classes this way. As I recall, we also
>>> didn't
>>> like the fact that it effectively limits the caller to one invocation of
>>> bind() per class hierarchy, since anything else would perform redundant
>>> binds as it walked up the tree.
>>> At this point, I could go either way. I can certainly see arguments for
>>> simplifying the method signature by reducing it to one argument. We could
>>> get around the private base member issue by only binding to private
>>> members
>>> in the leaf type; we'd only bind to public or protected members in the
>>> base
>>> classes. The need to bind to multiple classes in the same hiearchy does
>>> seem
>>> like an edge case.
>>> G
>>> On Nov 3, 2009, at 4:28 PM, Greg Brown wrote:
>>>> It allows the caller to specify which members to bind to. Without the
>>>> type
>>>> argument, bind() would need to walk up the type hierarchy and attempt to
>>>> bind to each superclass of the calling class as well as the class
>>>> itself. In
>>>> fact, it used to work that way, and at the moment I can't remember why
>>>> we
>>>> changed it. The single-arg signature does seem more intuitive.
>>>> On Nov 3, 2009, at 4:17 PM, Christopher Brind wrote:
>>>>> Hi,
>>>>> Just wondering what the logic is behind having two arguments for the
>>>>> bind method on the WTKXSerializer?
>>>>> Instead of:
>>>>>>  public <T> void bind(T t, Class<? super T> type) throws
>>>>>> {
>>>>>>    Field[] fields = type.getDeclaredFields();
>>>>> Why not:
>>>>>>  public <T> void bind(T t) throws BindException {
>>>>>>    Field[] fields = t.getClass().getDeclaredFields();
>>>>> In fact, why is this parameterised at all?  Wouldn't this suffice?
>>>>>>  public void bind(Object t) throws BindException {
>>>>>>    Field[] fields = t.getClass().getDeclaredFields();
>>>>> Cheers,
>>>>> Chris

View raw message