Support nested collections in the xtext OCL console

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 474933 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 13, 2015 16:57 EDT | | Modified | Aug 15, 2015 08:52 EDT | | Reporter | Marcus Huewe |

Description

Created attachment 255853\ Support nested collections in the xtext OCL console

Currently, the xtext OCL console just displays

"java.lang.UnsupportedOperationException"

if the specified OCL expression (e.g., "Set{Set{}}") evaluates to a\ nested collection.\ The attached patch contains a potential fix and enhances the existing\ "ConsoleTests" testcase.

:notepad_spiral: 0001-Support-nested-collections-in-the-xtext-OCL-console.patch

[eclipse-ocl-bot]

By Ed Willink on Aug 14, 2015 06:19

Thanks and a JUnit test too!

I'm not at all sure about the fix. The UnsupportedOperationException is commented:

// Must invoke DomainStandardLibrary.valueOf() for aggregates

which rather suggests that the problem is in the caller rather than callee. But DomainStandardLibrary.valueOf() is long gone, so need to investigate.

[eclipse-ocl-bot]

By Ed Willink on Aug 14, 2015 06:22

(In reply to Marcus Huewe from comment #0)

Created attachment 255853 [details]

Please sign the CLA by following the link next to your name in Bugzilla. This enables me to use rather than rewrite your test case.

[eclipse-ocl-bot]

By Ed Willink on Aug 14, 2015 06:49

(In reply to Ed Willink from comment #1)

// Must invoke DomainStandardLibrary.valueOf() for aggregates

This is a bit of a red herring. In the current code it should read

// Must invoke IdResolver.boxedValueOf() for aggregates

but we already have a CollectionValue so it doesn't need boxing.

Just changing:

ValueUtil.stringValueOf(elementValue)

to

elementValue.toString()

makes the new JUnit test pass, since CollectionValue has a toString override that imposes a 100 character limit on its content.

Simpler still ValueUtil.stringValueOf has a commented out\ \ else if (aValue instanceof Value) {\ stringValue = ((Value)aValue).toString();\ }

that does what is needed. (Looks like it was over-optimized away.)

[eclipse-ocl-bot]

By Marcus Huewe on Aug 15, 2015 06:12

(In reply to Ed Willink from comment #3)

Just changing:

ValueUtil.stringValueOf(elementValue)

to

elementValue.toString()

makes the new JUnit test pass, since CollectionValue has a toString override that imposes a 100 character limit on its content.

Yes, that is another issue. IMHO, it would be nice if the user could\ influence the way how the results are displayed. For this, I would propose\ the following:

• the class "Value" (from Values.ecore) implements the "Visitable" interface\ (from Pivot.ecore)
• move the toString(...) code into a default visitor
• add a new extension point to the "org.eclipse.ocl.examples.xtext.console"\ plugin (so that custom visitors can be registered)
• optional: add a dropdown menu to the console view so that a registered visitor\ can be selected

Rationale:

• sometimes the 100 character limit is a bit "annoying" (esp. if the objects\ have no custom toString() implementation)

• support for pretty-printing:\ For instance, the evaluation result of "Set{Set{Tuple{a = 4, b = 5}}}"\ could be displayed as\ Set{\ Set{\ Tuple{\ a : Integer = 4,\ b : Integer = 5\ }\ }\ }

  (IMHO that is quite convenient for nested collections that also embed\ tuples)

What do you think? If you like, I can try to come up with a patch for this.

[eclipse-ocl-bot]

By Marcus Huewe on Aug 15, 2015 06:21

(In reply to Ed Willink from comment #2)

(In reply to Marcus Huewe from comment #0)

Created attachment 255853 [details]

Please sign the CLA by following the link next to your name in Bugzilla. This enables me to use rather than rewrite your test case.

Hmm is this really needed for such a simple change (nearly everyone could\ have come up with this...)?\ I authored 100% of the patch's content - feel free to reuse it\ (does this help?)

[eclipse-ocl-bot]

By Ed Willink on Aug 15, 2015 08:50

(In reply to Marcus Huewe from comment #4)

(IMHO that is quite convenient for nested collections that also embed tuples)

What do you think? If you like, I can try to come up with a patch for this.

In https://wiki.eclipse.org/OCL/Debugger I outlined ideas for improved OCL UI.

The most important, the Debugger and validations View, have happened to a useable though not high quality extent.

The interactive console remains to be improved. The main improvement being the use of the Variables View, or equivalent, to display the results. Compromises on string rendering should then vanish.

--

Getting Value to implement Visitable would be good and ValueUtil.accept could invoke XXXValue.accept/visitXXX directly for Value classes and visitXXX indirectly for non-Value classes such as Boolean and String.

The "org.eclipse.ocl.pivot.internal.values" package name is incompatible with fully automated genmodeling, so it probably needs a change so that a Values variant of /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GenerateAutoCGModels.mwe2 could be used.

[eclipse-ocl-bot]

By Ed Willink on Aug 15, 2015 08:52

(In reply to Marcus Huewe from comment #5)

Please sign the CLA by following the link next to your name in Bugzilla. This enables me to use rather than rewrite your test case.

Hmm is this really needed for such a simple change (nearly everyone could have come up with this...)? I authored 100% of the patch's content - feel free to reuse it (does this help?)

The authorship claim helps, but Eclipse IP are very keen on the CLA. You only have to sign it once, not every time.