Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] API reviews

Hi Ed,

Thanks. Additional comments

[I think mentioned time ago, when deprecating use javadoc comments so tooling helps to lead the user to proper API replacement/reason of deprecation without any need to navigate source code (if present at all)]

I don't think that it's a good idea maintaining those deprecated methods any longer:
- Deprecated API in the promoted 1.0.0 plugins is awkward.
- It only make sense to reduce hiccups for release train projects, which were using non-promoted code, mainly, QVTd which we maintain, Acceleo/UML for which I think you are providing the patches anyway. They should increase plugin versions due to the promotion, let's force them to use the new API to avoid new hiccups in the future (and have cleaner interfaces). - M6 is API freeze, so let's remove them now (next week) so they have the whole milestone to align.

I'm OK with XXXXInternal classes, but I suggest moving them to internal packages, so JDT produce warning for clients when using them.

I'll create a new commit on ewillink/ocl25 with proposed comments, and any other suggestion I can detect.


On 04/02/2015 12:44, Ed Willink wrote:
Hi Adolfo

Thanks for the reviews.

Most have been incorporated on ewillink/ocl25.

I'm trying to follow a policy of retaining M5 public API till M7, so
some of your removals are just @Deprecated at present.

getClass_() is a necessary evil for Ecore auto-generation. Manually we
can do better, so I've used getPivotClass(). I'm surpised you found so
much that could change from Type to Class. Possibly just exposes the
next level. e.g. getCommonType might be changeable to getCommonClass etc.

OCLInternal and MetamodelManagerInternal have been factored out, so I
think there are now no XXX.Internal classes.

OCL.newInstance(EPackage.Registry) now creates a very lightweight OCL,
understanding only the nsURIs in the EPackage.Registry (and any delegates).

OCL.newInstance(ResourceSet) no longer creates a distinct

EnvironmentFactory.createParserContext is potentially important, though
perhaps only as internal API. It performs the extensible AS
class-specific preparation of the context for parsing an OCL expression.
i.e. an Operation.bodyExpression has parameter names. Creation of
parserContext was all over the place. I introduced a central
replacement, but seem not to have exploited it universally yet.


         Ed Willink
_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit

Back to the top