Parser Constants could be Better Organized

[eclipse-ocl-bot]

| --- | --- |
| Bugzilla Link | 116662 |
| Status | CLOSED FIXED |
| Importance | P3 normal |
| Reported | Nov 16, 2005 09:15 EDT |
| Modified | May 27, 2011 02:40 EDT |
| Version | 1.0.0 |
| Reporter | Vishy Ramaswamy |

Description

Constant string and integer values in the OCL parser code could be better
organized than they are, for maintainability of the code.

The table of operation codes (ints) should be centralized to more easily
ensure that there is no overlap. These should be collocated with the
corresponding operation names and the utility methods that convert between
them.

The OCL syntax help support defines a large number of constant strings for the
standard OCL operations. If possible, these suggestions should always be
derived from the OCL parser's implementation of the OclAny, Collection,
primitive, and other appropriate types. This requires a more complete
specification of the EOperations in those types (such as including names for
the parameters). This will then ensure that all syntax help is derived at run-
time

[eclipse-ocl-bot]

By Christian Damus on Apr 05, 2006 15:12

Completely reworked the definitions of the OCL Standard Library operations, so that content assist is fully generic. One of the benefits of this was enabling resolution of generic type parameters in operation signatures when providing suggestions, such as

"union(Set(Foo)) : Set(Foo)"

instead of

"union(Set(T)) : Set(T)"

for a Set of Foos.

[eclipse-ocl-bot]

By Nick Boldt on Jan 28, 2008 16:35

Move to verified as per bug 206558.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:37

Closing after over a year in verified state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:40

Closing after over a year in verified state.