pojomatic-users

[Pojomatic-users] Handling annotations on interfaces

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

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:

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

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
>

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
>

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