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 <[email protected]>:
> 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 <[email protected]>:
>>>
>>> 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
>>>>
>>>
>>>
>
>
