[pivot] Introduce ?. operator

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 402103 | | Status | NEW | | Importance | P3 enhancement | | Reported | Mar 01, 2013 04:48 EDT | | Modified | Mar 01, 2013 06:11 EDT | | Reporter | Ed Willink |

Description

As motivate by https://bugs.eclipse.org/bugs/show_bug.cgi?id=401915#c9 introduce an x.?y operator such that

(x.?y) = (if x == null then null else x.y endif)

Since this is syntax sugar it has no deep impact on OCL, though for efficiencyt it wants to be a third navigation operator in a PropertyCallExp.

This should be backed up by validation to warn that in

a.b

a may be null or that in

a.?b

a cannot be null, using the TypedElement.isRequired field already present.

[eclipse-ocl-bot]

By Laurent Goubet on Mar 01, 2013 05:08

This seems like unnecessary complexity to me. Users are already puzzled about the two navigation operators of OCL. Introducing a third one seems like a good way to confuse them even further. This does not sound like syntactic sugar: it will make the expressions that much more complex to read and write (and, as I see it, most users will probably never use the simple "." when the ".?" is so much more useful).

What I mentionned in bug 401915, comment #c9, this very functionality, is already provided through the lax null handling option. However, the option does not go all the way, it only handles very few use cases. If I told OCL to be lax in its null handling, I expect "a.b" to return null instead of "invalid" when "a" is "null".

[eclipse-ocl-bot]

By Ed Willink on Mar 01, 2013 05:11

Correction, the operator should be ?. rather than .?

In Groovy and Xbase this is called a Safe Navigation Operator.

OMG Issue raised.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 01, 2013 05:45

Hi Ed, Laurent,

Apologise if I missing something.

I agree with Ed that it may be considered as a matter of syntactic sugar. I mean is like some QVTo "shorthands":

source.children![MyClass] => source.children->select(MyClass)->first()

so

source?.doSomething() => if source = null then null else source.doSomething() endif

However, a good Laurent's point is the following:

"most users will probably never use the simple "." when the ".?" is so much more useful"

I'd definitely prefer a unique way of writing expressions and some kind of Evaluation Mode (strict and lax, or whatever) in which the navigation of null values are controlled by the evaluator. Perhaps some kind of declaration in the CompleteOCL documents (in a similar way html use doctypes to set different levels of strictness/conformance)

The only contrary point I see is the situation in which you could expect some mixed strict and lax situations when you are defining the document with your constraints. I'm not sure if this make sense at all, though... If you want "lax null handling" is because you want to ease constraints writing and then you will probably want to do it everywhere.

Defining some kind of declaration or directive in OCL Documents, should avoid problems when porting your OCL constraints along different tools, as long as they are compliant with the spec ;).

P.S: Note that QVTo also defines the "strict" model type feature, with a different purpose.\ P.S2: Another point to take into account is EssentialOCL.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Ed Willink on Mar 01, 2013 06:11

Many of the existing operator problems come from poor tools.

If you don't instantly get a warning squiggle for the wrong ./->/... then how can users learn/just ignore and carry on.

The dreadful tooling is going away.

In Java, we have a similar issue with Bye-Bye NPE, and @NonNull annotations that are useful but only in so far they go. Some JSR is pending to permit List<@NonNull String>.

In a modelled OCL we can have all this.

operation and(b : Boolean[?]) : Boolean[?] validating invalidating

b : Boolean[?] => argument may be null\ : Boolean[?] => result may be null\ validating => an invalid input may yield a valid result\ invalidating => a valid input may yield an invalid result

Few operations are as horrible as Boolean::and.

This information has always been there just hidden and ignored.

null-analysis can exploit it and warn users of dangereous null navigation.

[Of course (a?->b) = (a->excluding(null)->b)]