|[mdt-ocl.dev] Legacy support for Juno|
HiSince 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