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 <[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
