|Re: [p2-dev] @noimplement on IMetadataRepository ?|
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.
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.