I think the real issue here is; Is p2 in any way dependent on that the
underlying implementation uses the abstract base class?
If it's not, I suggest we replace the @noimplement with javadoc
informing the reader about the abstract class, leaving the choice of
using it to him. The @noimplement gives the impression that you're
doing something wrong defying it although its actually OK.
- thomas
On 02/18/2010 04:51 PM, John Arthorne wrote:
Yikes, I didn't mean to start an EMF holy war here, I was
just explaining the reasoning behind using an abstract base class. I
can understand that EMF uses base classes for exactly the same reason
and completely agree there's no easy answer here. The difference in my
mind is that EMF is a technology that is used to implement
domain-specific models, so this limitation affects what kinds of
domain-specific APIs can be implemented via EMF (only purely
interface-based APIs). IMetadataRepository *is* the domain-specific
model in this case, and it seemed unjustified to impose limitations on
the design of this API to satisfy the constraints of one particular
technology that can be used to implement the API (EMF in this case). I
doubt that line of reasoning will convince anyone but this is what I
was thinking when I made the statement about the EMF limitation.
Is a possible solution here to create a subclass of
AbstractMetadataRepository that encapsulates an EMF model implementing
the guts of the repository behavior? I can imagine in many cases a
wrapper isn't a scalable answer, but in this case the set of repository
instances is going to be very small.
John
On Tue, Feb 16, 2010 at 11:05 AM, Ed Merks <ed.merks@xxxxxxxxx>
wrote:
John,
EMF has the same issue about subclassing EObject/InternalEObject rather
than extending the base class, i.e., BasicEObjectImpl or one of its
derivatives. Yes, it's a harsh limitation, one we share with
IMetaDataRepository and the other Eclipse APIs to which you refer. Of
course we could change the generator effectively to copy
BasicEObjectImpl into some other class we extend, but that still leaves
the client with a copy rather than a reusable base we can modify in the
future. In any case, we must realize that an abstract base isn't a
panacea for API migration given it's not always possible for an
abstract base to implement fully whatever new thing is added to the
API, e.g., the EObject.eInvoke API that was added this release.
Cheers,
Ed
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|