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:44:21 GMT
But what if I don't want to bind the members of the super-class?

The multi-arg version facilitates binding in the super class - the
caller just calls it multiple times.  However, if you put the walk up
functionality in to these methods the caller won't have any choice
about it at all.

Having the single arg version call the multi-arg version with a call
to getClass gives everyone the most flexibility and doesn't change it
from how it is working now.

Cheers,
Chris



2009/11/3 Greg Brown <gkbrown@mac.com>:
> That would work, though I might want the single arg version to walk up the
> tree and call the multi-arg version for each base class. That would mean
> that the multi-arg version should compare the type of "t" to the given type
> and only bind to private members if they are the same. But that is probably
> a good thing to do anyways, even without adding the single-arg version.
>
> We could call isAssignableFrom() instead of using the template parameter to
> ensure that callers can only bind to classes in the same hierarchy.
>
>
> On Nov 3, 2009, at 5:15 PM, Todd Volkert wrote:
>
>> +1 - that seems like a good compromise (I don't really feel like
>> re-architecting an app that's already in production, and I don't really
>> like
>> limiting the caller's options in terms of class hierarchy).
>>
>> The generic type is preventing you from saying wtkxSerializer.bind(this,
>> Foo.class) if you're in a class that is not Foo or a subclass of Foo.
>>  It's
>> not really adding much value.
>>
>> -T
>>
>> On Tue, Nov 3, 2009 at 5:10 PM, Christopher Brind
>> <brindy@brindy.org.uk>wrote:
>>
>>> 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