Re: [Pojomatic-users] Handling annotations on interfaces

[Ian R. <ian...@gm...>]

On Wed, Jul 8, 2009 at 11:21 PM, Chris Hansen <han...@gm...>wrote:

> I don't have strong feelings one way or another, so my opinions are
> based upon the "principle of least astonishment".
>
> My gut reaction is to include annotated properties from interfaces,
> just because they must have been placed for a purpose and it would
> therefore seem discourteous to ignore them ;) . A better reason is
> that the @Property annotations present on an interface can be seen as
> a part of the API that comes along with implementing the interface,
> the same way the properties are inherited when you extend a class.
>

I've been thinking about this.  If property annotations are "part of the
interface", then it's likely that the interface is defining what equals
means.  In this case, it's likely that the implementors should not be
defining their own pojomators.   Specifically, the point of an interface
defining what equals means is to allow equality between different
implementations (java.util.List provides a good example of this). For this
to work, the equals method needs to do it's instanceof check against the
interface class, not the implementing class.  In turn, this means that the
pojomator would need to be defined on the interface class.

So while having pojomatic walk the interface hierarchy for a class might
have pojomatic doing what the client expected, it very likely is not doing
what the client really wants.  Or at least, not in any of the use cases I've
been able to come up with...


> As for creating a Pojomator instance for an interface, I think the
> expected behavior would be to walk up the inheritance hierarchy of the
> given interface only and use all @Property annotations found. I'm not
> quite sure if that is exactly what you proposed or slightly different.


That is in line with what I was thinking.  Although now I'm wondering
whether it even makes sense to walk up the hierarchy for an interface, based
on my comments above...

What do you think, Ian? Am I correct that these behaviors would be expected?
>
> Also, do you agree that (barring unforeseen events/bugs), the next
> release candidate should be the last before 1.0?


Agreed.


> Sorry it took so long for me to reply.


No worries :).

  - Ian


> -Chris
>
> > From: Ian Robertson <ian...@gm...>
> > Date: Fri, 19 Jun 2009 10:58:05 -0600
> > To: <poj...@li...>
> > Subject: [Pojomatic-users] Handling annotations on interfaces
> >
> > Currently, Pojomatic ignores annotations on any interfaces a class might
> > implement.  Moreover, it is not possible to create a pojomator for an
> > interface, since ClassProperties walks up the superclass hierarchy until
> it
> > hits Object.class, but  the superclass of an interface is null, so we get
> a
> > NullPointerException.
> >
> > I can see at least two use cases for supporting Pojomators for
> interfaces:
> >
> > If an interface defines the behavior of equals and  hashCode as part of
> its
> > contract, it could include @Property annotations and a public static
> > Pojomator instance which implementing classes could use for their equals
> and
> > hashCode implementations.
> > If someone needs to be able to check equality on a subset of properties
> of
> > SomeClass (independently of SomeClass's equals method), they can define
> an
> > interface with only those properties, annotate those properties (on the
> > interface) and then have SomeClass implement that interface.  Finally,
> they
> > could use the pojomator for the interface to check equality of just the
> > properties in question.
> >
> > What I would like to propose is that if ClassProperties is constructed
> for
> > an interface, that it walk up the implementors hierarchy instead of the
> > superclass hierarchy; classes would continue to be handled as they are
> > today.  As such, this is a non-breaking change.  However, I would not be
> > surprised to see an argument being made that, when constructing
> > ClassProperties for a class, that we should not only examine super
> classes
> > for annotations, but also interfaces.
> >
> > My personal opinion is that the pojomator for a class should not include
> > properties annotated on any of interfaces which the class implements.  If
> an
> > interface wishes to specify how equals and hashCode should be
> implemented,
> > it can do so as described in the first use case above.  But in general, a
> > class implementation should not need to worry about what annotations
> might
> > or might not be present on its interfaces.
> >
> > What do others think about this?  Should the pojomator for a class
> include
> > annotated properties from interfaces or not?
> >
> >   - Ian
> >
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Pojomatic-users mailing list
> Poj...@li...
> https://lists.sourceforge.net/lists/listinfo/pojomatic-users
>