John,
Comments below.
John Arthorne wrote:
Yikes, I didn't mean to start an EMF holy war here,
Hehehe. The wrath of the righteous. :-P
I was just explaining the reasoning behind using an
abstract base class.
It makes good sense.
I can understand that EMF uses base classes for exactly
the same reason and completely agree there's no easy answer here.
Yep. In the end, even an abstract base class is a bit of a false sense
of security. Certainly one can keep the compiler happy but can one
really ensure that a good implementation can be provided in the base?
Only if it's possible to delegate everything only existing other
methods, in which case, it could be done as an external utility...
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).
Yes. For example, sometimes folks express a design to have an
exception modeled as an EClass; that runs into the same problem.
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).
Maybe I'm splitting hairs or mincing words, but you're imposing
limitations on the implementation of the API in order to preserve the
flexibility of evolving that API.
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.
It's definitely reasonable to call it a 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.
I imagine that's possible. You might model an analog/copy of the
interesting methods and accessors for IMetaDataRepository and its
supertypes and provide an accessor that returns a "real"
IMetaDataRepository that extends AbstractMetadataRepository, which in
turn is extended to produce the expected notifications. Sounds a bit
messy...
One might imagine someone wanting a CDO-backed implementation where the
objects don't carry any data directly but rather communicate with
another process in response to all method calls, i.e., they just
provide a view on a centrally maintained shared instance. That's not
possible when AbstractMetadataRepository has determined that the
implementation necessarily carries/caches the data in fields within the
object.
In any case, design generally involves trade-offs and who's really to
say what's ideal given that ideal varies depending on one's perspective.
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
|