[project] Ideas for future MDT-OCL component

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 237438 | | Status | NEW | | Importance | P3 enhancement | | Reported | Jun 17, 2008 04:44 EDT | | Modified | Jun 26, 2010 11:30 EDT | | Version | 1.2.0 | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

Hi Christian,

I presume that you have several ideas in mind related to why a new component should be achieved.

I give you the honors to start the debate.

Cheers,\ Adolfo.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Dec 16, 2008 11:27

About Standard Library improvement:

Apart from complying with the new OCL 2.1 resolved issues, OCL Standard Library must better organize the stdlib M1 model, there is a bug pending for it:\ https://bugs.eclipse.org/bugs/show_bug.cgi?id=189657.

In addition, I have been thinking about another related problem. On the one hand, OCL spec doesn't mention anything about how that Standard Library must be implemented (just what types/operations must have). On the other hand, OCL Spec does mention about complete OCL and basic OCL (or EssentialOCL, which QVT, indeed, extends). However, the spec doesn't mention anything about what to do with the OCLStdlib for EssentialOCL (the MDT OCL Ecore-based implementation). OclElement and OclMessage types don't make sense in EssentialOCL.

Apart from raising an issue to OMG to tend to clarify this aspect, what do you think about trying to organize this stuff for MDT-OCL 2.0.0 ?

I suppose that at API level OCLStandardLibrary we can't do too much, since we have a a generic component, which should cover Complete OCL. However, we can do at M1 models. I think that those types which don't make sense in EssentialOCL can be removed from a possible oclstdlib.oclecore.

More things:

Target Milestone -> 2.0.0 ?\ What do you think about making this bug depend on all 2.0.0 bugs ? I think that having a central bug is useful for those which better prefer web browser instead of mylyn (Actually, I usually use the former ;P)

[eclipse-ocl-bot]

By Ed Willink on Jan 20, 2009 11:01

I have a fair few ideas that could be considered once an API freeze is lifted; please raise a separate Bugzilla for non-trivial discussion on each one and just identify the Bugzilla from here.

---

Consistently nested environments.

A LetExp temporarily upgrades its environment while processing its body. It would be much better to pass a nested environment. This would ensure that AST nodes can maintain persistent references to their environments allowing re-use of scope information for editing problems such as completion proposals.

---

Two pass analysis

The QVT analysers all use two passes, one to find definitions and a second to resolve them. The OCL analyser uses just one and so is unable to resolve forward references.

---

CST cleanup

The constraint daisy chain has been duplicated by a clean constraints collection. I overlooked a similar invOrDef daisy chain.

PathNameCS should be a sequence of SimpleNameCS. This is easy in the grammar but has a major ripple to lookup signatures. Provision of the missing CST nodes avoids the need for subsequent workarounds for irregular behaviour.

Deprecated properties could be pruned.

The strange resolution of numeric operation calls in the lexer rather than parser should be reviewed.

---

AST cleanup

The OCL specification howler on Constraint::constrainedElement\ (bug 257746) should be resolved, so that an editor AST outline can show a feature name.

---

Typos

The trivial spelling mistakes such as ExpressionInOCL should be spelled ExpressionInOcl (bug 215110) could be fixed, perhaps with derived deprecated classes persisting old names.

---

Non-navigable navigation

A solution to non-navigable navigation could be provided (bug 251621),

---

Import

An import construct could be introduced.

---

Meta-class literals

A meta-class literal could be introduced to solve the problem of writing a constraint that a model element's meta-class is in the EssentialOCL package.

[eclipse-ocl-bot]

By Christian Damus on Jan 21, 2009 09:12

(In reply to comment #1)

In addition, I have been thinking about another related problem. On the one hand, OCL spec doesn't mention anything about how that Standard Library must be implemented (just what types/operations must have). On the other hand, OCL Spec does mention about complete OCL and basic OCL (or EssentialOCL, which QVT, indeed, extends). However, the spec doesn't mention anything about what to do with the OCLStdlib for EssentialOCL (the MDT OCL Ecore-based implementation).

Good observations. These are good issues for the RTF.

OclElement and OclMessage types don't make sense in EssentialOCL.

OclElement just doesn't make sense. :-P I think that among the resolutions adopted for 2.1 is one that eliminates it.

Apart from raising an issue to OMG to tend to clarify this aspect, what do you think about trying to organize this stuff for MDT-OCL 2.0.0 ?

Yep. Good idea.

I suppose that at API level OCLStandardLibrary we can't do too much, since we have a a generic component, which should cover Complete OCL. However, we can do at M1 models. I think that those types which don't make sense in EssentialOCL can be removed from a possible oclstdlib.oclecore.

Your recent note on the mailing list about separating these two dialects would probably help.

One thing, though, that I wouldn't want to lose is the ability for other metamodels to be bound. Those that are EMOF-like in their capabilities could implement EssentialOcl, while those that have UML-like capabilities could implement CompleteOcl (more or less). I'm not sure how that would work, but we do already have customers that have integrated their DSLs into OCL using the generic API.

More things:

Target Milestone -> 2.0.0 ? What do you think about making this bug depend on all 2.0.0 bugs ? I think that having a central bug is useful for those which better prefer web browser instead of mylyn (Actually, I usually use the former ;P)

Absolutely! It works very well for Mylyn users like me, too.

[eclipse-ocl-bot]

By Christian Damus on Jan 21, 2009 09:29

(In reply to comment #2)

I have a fair few ideas that could be considered once an API freeze is lifted; please raise a separate Bugzilla for non-trivial discussion on each one and just identify the Bugzilla from here.

I'll just insert a few trivial questions/comments in here before these discussions go their separate ways. ;-)

Consistently nested environments.

Do AST nodes currently reference their environments?

Two pass analysis

Yes, this sounds like a good idea.

CST cleanup

Some of this is a fairly literal interpretation of the grammar in spec ch 9, which is rather awkward and sometimes inaccurate/incomplete. The OCL spec doesn't define a CST model, so I think we there are no compliance issues in making these changes.

AST cleanup

Let's make sure that this is raised as an issue for the RTF.

Typos

The usage of upper-case acronyms in the metamodel API was mandated by the project to which the OCL component was originally contributed. The names originally matched the specification, but we were compelled to change them as a condition of acceptance of the contribution. Note that XMI serialization uses the expected names.

What is the MDT project's policy? Note that we have introduced names such as OCLStandardLibrary::getOclAny() since the original contribution. :-)

Non-navigable navigation

Or, extensibility could be provided that lets other languages implement this. Of course, it may be just as easy to implement it with some sort of compliance-checking option.

Import

Another good idea for an OCL RTF enhancement.

Meta-class literals

I think the OCL 2.1 spec will cover this. e.g.,

context \ inv: implies\ self.oclType().oclType().getPackage().name = 'EssentialOcl'

[eclipse-ocl-bot]

By Ed Willink on Jan 21, 2009 11:07

Consistently nested environments.

Do AST nodes currently reference their environments?

The derived QVT CSTEnvironment is installed as an adapter on the AST node,\ so that the Environment is visible from but not serialised with the AST node.\ The Environment also provides better AST to CST navigation.

[eclipse-ocl-bot]

By Ed Willink on Feb 19, 2009 13:30

Migrate unescaping to lexer as discussed in bug #242880, changing StringLiteralExpCS representation to match StringLiteralExp.

[eclipse-ocl-bot]

By Ed Willink on Mar 15, 2009 04:34

It would be good to allow oclstdlib.uml to be user definable to exploit UML package merges and have all internal functionality including oclstdlib.ecore derived dynamically. See bug #268660.

[eclipse-ocl-bot]

By Ed Willink on Jun 09, 2009 11:34

It would be good to have a flexible visitor/transformation suite to support generation of good Java, C, VHDL with exyensibility to e.g. QVT's ImperativeOCL.

See bug 279638.

[eclipse-ocl-bot]

By Laurent Goubet on Jun 26, 2009 15:17

I wonder if we could try and push some other things in the specification too (or try to :p). There are several features of QVTO's extended grammar that I would truly like to see in the base grammar. And yes, I am talking about syntactic sugar :).

First thing I truly miss when writing OCL expressions, be it with the base OCL through the interpreter example or within Acceleo generators -I am currently investigating extending the grammar within Acceleo as it's been done in QVTO- is the "+" operator between Strings as a shortcut for concat(). Using "+" has just become that intuitive within most languages that one lacking it seems ... unreal :).

A second feature I find just totally awesome (okay, I might be biased as it existed too in the "old" Acceleo, before we came to adopting the OMG MTL standard along with OCL) is the list filtering through bracketed expression so that\ "package.classes()[attributes.size() != 0]" is a shortcut for "package.classes()->select(attributes.size() != 0)". I just love that syntax.

And third would be the addition of shortcut operators for collections' "union" and ... well I don't know if an OCL equivalent to java's "removeAll" exists for Collections except for the already existing "-" for Sets and OrderedSets.\ "package1.classes() + package2.classes()" would then be an equivalent for Java's "package1.classes().addAll(package2.classes())"\ where\ "package1.classes() - package2.classes()" would be equivalent to "package1.classes().removeAll(package2.classes())"

I believe these would make for fine additions to EssentialOCL ... and do keep in mind that I have yet to fully familiarize myself with the last version of the specification, so these might already be in.

[eclipse-ocl-bot]

By Laurent Goubet on Jun 26, 2009 17:04

Trying to split the discussions in their own bugzillas :

1) Addition of a "+" operation between Strings as a shortcut for the concat() operation can be discussed in bug 281710 2) Addition of both "+" and "-" operators on OCL collection types in bug 291715 3) "bracket expression" list filtering in bug 281717

[eclipse-ocl-bot]

By Laurent Goubet on Jun 26, 2009 17:06

2) is of course bug 281715 (curse these uneditable entries :( )

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2009 04:57

I will start rationalising the duplicated JUnit test structure as a top priority so that all new tests have a simpler framework. See bug 254919.

[eclipse-ocl-bot]

By Radomil Dvorak on Jun 29, 2009 05:28

(In reply to comment #9)\ I'm writing my comment here instead of into individiual SCRs related \ to extensions, as IMO it rather applies in general.\ Surely, there might be a lot of great improvements to the language. \ As per my experience, MDT OCL does not prevent clients from implementing features like this.\ Would not MDT OCL customers be happy for continuous effort in extensibility, flexibility (which is also why MDT OCL has become a crucial component to them)?\ Can we get a promise that EssentialOCL will remain essential ;)?

[eclipse-ocl-bot]

By Alexander Igdalov on Jun 29, 2009 06:58

(In reply to comment #13)

MDT OCL is aimed to be an implementation of the OMG standard and maintain currency with the latest specification (bug 156363). Since the latter hasn't yet been published it is too early to say how to treat language extensibility issues such as proposed in comment #9. If they become a part of the standard they will be added to the basic grammar. If not - they might become implementation specific extensions which are required by some downstream projects. Remember that dialect of the ImperativeOCL which was used in GMF XPand? They could have chosen pure OCL but they preferred to have the syntactic sugar.

However, since the primary goal of the component is to be aligned with the standard, MDT OCL clients should always have the default option to use the pure language.

[eclipse-ocl-bot]

By Ed Willink on Jul 03, 2009 07:05

Bug 282365 discusses some options for extended validation within an editor to determine whether the set of constraints is consistent and independent.

[eclipse-ocl-bot]

By Ed Willink on Aug 14, 2009 10:47

Bug 286644 identifies the omission of support for generics, which would be useful to fully exploit Ecore or UML.

[eclipse-ocl-bot]

By Ed Willink on Jun 26, 2010 11:30

Rolling over for Indigo.