[mdt-ocl.dev] Legacy support for Juno

[Ed Willink <ed@xxxxxxxxxxxxx>]

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