Re: [Pojomatic-users] Handling annotations on interfaces

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

On Thu, Jul 9, 2009 at 9:46 AM, Ian Robertson<ian...@gm...> wrote:
> 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...

I think that makes sense, and I agree.

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

I think that only the annotations on the interface should be used
(i.e. do not walk up the hierarchy). Then, the creator of the
interface could declare any methods from super-interfaces which should
be included as properties. That would mean the creator of the
interface would have full control over which properties are
included/excluded. To me, having full control of the interface is more
important than it would be for a concrete class because concrete
classes already depend on some of the implementation details of their
super-classes. Do you agree?

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