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



Cheers,
Chris


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
BindException
>>>>>> {
>>>>>>    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
>>>>
>>>
>>>
>
>

Mime
View raw message