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