Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-ocl.dev] Legacy support for Juno

Hi

Since the pivot support is not being promoted for Juno, we have another year with the legacy Ecore and UML bindings as the 'preferred' user environment, so we need to reduce as many pain points as possible.

New syntax/library operations are pretty safe; what was a syntax error is now useful. Semantic changes may be too difficult. So:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=377374 (review pending) solves the problem that a Complete OCL file created by the Xtext editor cannot be used by the Ecore Java API because import statements are syntax errors. The fix allows but ignores the import syntax, allowing the file to be loaded, but requires the correct environment setup in the Java call.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=373518 introduced URI package qualification: _'http:/...'::XX::yy, which is needed for type expressions in OCLinEcore; probably a step too far.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=349117 supporting Long tuple elements was 90% done; I'll see if it can be finished off.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=367822 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=364797 on overloading/overriding might be tractable.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=309459 introduced selectByKind and selectByType to eliminate the oclIsKindOf...oclAsType redundancy. This affects the IA so probably can't do.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=373289 added many new String operations particularly for regex. Reassured that the Impact Analyser is unaffected by boring String operations, I'm about to try to retrofit as many of the missing library operations as possible. This should make edit and run very compatible, except at the avoidable labnguage edges. I doubt that I will change the old syntax helper unless it's a trivial add-name-to-list change.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=152207 has been requesting toString() for ages and of course we could spell 'invalid' better than an EMF default.

The current library discrepancies affect:

OclAny:: <, >, <=, >=
OclAny::oclType()
Boolean::toString()
Integer::toString()
Integer::compareTo()
Real::toString()
Real::compareTo()
String::+
String::at()
String::characters()
String::compareTo()
String::endsWith()
String::equalsIgnoreCase()
String::indexOf()
String::lastIndexOf()
String::matches()
String::replaceAll()
String::replaceFirst()
String::startsWith()
String::substituteAll()
String::substituteFirst()
String::substring()
String::toBoolean()
String::toLowerCase()
String::toString()
String::toUpperCase()
String::tokenize(*3)
String::trim()
Collection::collectNested()
Collection::reject()
Collection::select()
Collection::sortedBy()
Collection::asBag()
Collection::asOrderedSet()
Collection::asSequence()
Collection::asSet()
Collection::excluding()
Collection::flatten()
Collection::including()
Collection::max()
Collection::min()
Collection::selectByKind()
Collection::selectByType()

most of these can be eliminated.

    Regards

        Ed Willink


Back to the top