Bug 490443

Summary:	Improve validation for expressions which return a collection when we expect a scalar (and vice versa)
Product:	[Modeling] Sirius	Reporter:	Pierre-Charles David <pierre-charles.david>
Component:	Core	Assignee:	Project inbox <sirius.core-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	maxime.porhel
Version:	3.1.0	Keywords:	triaged
Target Milestone:	---
Hardware:	All
OS:	All
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=489270
Whiteboard:

Description Pierre-Charles David

2016-03-25 10:25:37 EDT

In Bug 489270 - Problem with "Move operation" in Operation Action, the problem was that contrary to what the Query Legacy (and maybe MTL) interpreters did/do, when an AQL expression is evaluated via evaluateEObject() and the raw result is a singleton (array or collection) of EObject, it returns null. This is true for all interpreters derived from AbstractInterpreter, see AbstractInterpreter.evaluateEObject(EObject, String).

We could:
a) automatically unwrap such trivial collections when asked for a scalar. This has the risk of introducing some "magic" (implicit) behavior, but different users have different ideas of what kind of "magic" is to be expected (should we unwrap collections of collections? if the collection has two EObjects, should we abort or return the first?)
b) improve validation to tell the user something like "Type error: expected EObject but the expression returns a Collection<EObject>".

I'm leaning towards "b)", but open to discussion on whether "a)" should be done instead of in addition (we could have a flexible interpreter API with some automative coercions, *and* be more strict on the user-facing side).