|Re: [mdt-ocl.dev] 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.
Cheers, Adolfo. 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 externalResourceSet. 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. Regards Ed Willink _______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
Back to the top