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