Re: [Pojomatic-users] Handling annotations on interfaces

[Chris H. <han...@gm...>]

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.

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.

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?

Sorry it took so long for me to reply.

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