pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Volkert <tvolk...@gmail.com>
Subject Re: WTKXSerializer#bind
Date Tue, 03 Nov 2009 22:15:03 GMT
+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message