|Re: [mdt-ocl.dev] API reviews|
HiI've certainly never found OCL.newInstance(EPackage.Registry) very useful and indeed I've only just provided code that kind of supports it. Indeed other useful methods are relatively new, and five out of seven unused fields are only just being deprecated.
However identify-your-EPackages is the traditional start up for Ecore OCL, although the inconsistency between Ecore OCL and UML OCL package registration lookup has always been hard to explain.
I prefer to try to preserve the old API to reduce porting difficulties for users. OCL.newInstance(EPackage.Registry) is potentially the most efficient start-up since it can have no delegation and so shut out all global registrations and cause newbie difficulties. There should be no ResourceSet problems, a new external ResourceSet is created and perhaps not used since the usage is probably of compiled Java EPackages. Indeed an attempt to load a *.ecore may fail since *.ecore might not be registered.
Perhaps need to study what will be needed for CDO users. Regards Ed On 04/02/2015 15:47, Adolfo Sanchez-Barbudo Herrera wrote:
On 04/02/2015 12:44, Ed Willink wrote: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.Hi Ed,I've been thinking about this. As you may check from test cases, most OCL.newInstance(EPackage.Registry) usages come from doing ResourceSet.getPackageRegistry, which turns into returning a OCL instance with a distinct externalResourceSet.IMHO, users normally deal with ResourceSets and Resources, and they configure ResourceSet package registry as they need. Do you think that OCL.newInstance(EPackage.Registry) is really needed, and instead, shouldn't we just forcing them to deal with the OCL.newInstance(ResourceSet) one ? Do we want to give an open door to users to mess up with the resourceSets they think they are using ?. If so, at least, we should clearly document it in the OCL.newInstance(EPackage.Registry) method.Cheers, Adolfo. _______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5646 / Virus Database: 4281/9055 - Release Date: 02/04/15
Back to the top