db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.org>
Subject Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Date Fri, 12 Oct 2007 18:53:13 GMT
+!, f'shizzle, we need to remizzle & dizzepricate.

(I don't know why I wrote my comment using Snooplang. 
I must be punchy after talking for 4 days straight.)

--- cbeams <cbeams@gmail.com> wrote:

> I haven't fully reviewed this proposal, but I do
> know that using  
> implements/@Implements only served to confuse me in
> the past.  I kept  
> thinking: isn't this information superfluous? 
> Should the enhancer  
> have been able to figure this stuff out by static
> analysis?
> 
> So if it is in fact not needed, I'm a big +1.
> 
> Thanks,
> 
> - Chris Beams
> 
> On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
> 
> > Hi Ilan,
> >
> > +1 to remove/deprecate the implements element and
> @Implements  
> > annotation.
> >
> > If no adverse comments are received by Tuesday
> October 16, it's gone.
> >
> > On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
> >
> >> Hi,
> >>
> >> The 'Implements' annotation (and the equivalent
> XML element)  
> >> remind me
> >> the 'persistence-capable-superclass' XML
> attribute that is  
> >> deprecated now.
> >
> > Yes, for JDO 1, we tried to have it possible to
> enhance classes  
> > when not all of its dependencies (superclasses and
> implemented  
> > interfaces) were available for loading and
> analysis. In this  
> > environment, it was necessary to explicitly
> declare which  
> > interfaces were implemented because you could not
> load all of the  
> > directly implemented interfaces to see which
> persistence-capable  
> > interfaces were indirectly inherited.
> >
> > But now, enhancement requires access to the entire
> inheritance tree  
> > and it makes sense to also require the implements
> tree as well.
> >>
> >> If persistence capable interfaces are marked as
> such by annotations
> >> (or in the XML metadata), why should we have this
> duplication?
> >>
> >> Implementations should be able to find
> implemented persistence  
> >> capable
> >> interfaces as they find a super persistence
> capable class.
> >
> > True, and I support deprecating the xml attribute
> and removing the  
> > @Implements annotation.
> >
> > Unless someone can justify why there would be any
> semantic  
> > difference between explicitly declaring the
> interfaces versus the  
> > enhancer finding them. The only thing I can think
> of is whether an  
> > explicitly named interface would have an extent
> managed, but I  
> > think that you can only query over the extent of
> classes/interfaces  
> > that themselves declare that an extent is managed.
> >
> > Craig
> >>
> >> Ilan Kirsh
> >> ObjectDB Software
> >> http://www.objectdb.com
> >>
> >>
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> 
> 


Mime
View raw message