search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

Introduce support for 'static' features #406

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 285633 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Aug 04, 2009 16:31 EDT | | Modified | May 27, 2011 02:47 EDT | | Version | 1.3.0 | | Depends on | 285771 | | Reporter | Ed Willink |

Description

Implement the OCL 2.1 static features.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 05, 2009 16:09

Not as easy as it seems; parsing no problem, but

Neither EMOF nor Ecore support 'static'.

? support only on UML-binding

? use a comment/annotation/xmi:extension on Ecore/EMOF

? wait for opinion on Ecore enhancement request bug 285771

? implement as a Constraint rather than Feature property

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 07, 2009 13:20

I was mid-way through raising an OMG issue when I realised that there is no problem other than lack of clarity in the OCL 2.1 proposal.

'static' is only applicable to 'def' which is only applicable to 'Complete OCL' which expects underlying UML capabilities.

The problem is that once again the Ecore binding of MDT-OCL is over-reaching.

Therefore we seem to be left with an approach that introduces a DefConstraint that extends Constraint to add the isStatic feature. Evaluations must be sensitive to the need to examine their OCL-defined features more carefully.

Since the non-EssentialOCL AST is not defined by OMG we are free to introduce this extra AST class.

eclipse-ocl-bot commented 1 month ago

By Adolfo Sanchez-Barbudo Herrera on Aug 07, 2009 14:49

It seems that the "static" property of a feature has been considered along the MDT-OCL implementation via UMLReflection, whose implementation for the EcoreBinding consists in just returning false. AFAIU after reading the new draft about the related "static" modification, is just adding a way to define static features inside the OCL expression.

As you have noticed this only concerns the non-Essential grammar and CST. Besides, you will have AbstractOCLAnalyzer to set the static property when analyzing the defCS node, via a new UMLReflection.setStatic method (which would do nothing in the EcoreBinding implementation), would suffice. What do you think ? ;)

I'm also a little bit worried because I haven't been able to finish the study of LPG v2 (my fault) because I have been too busy at work. I must solve that point (Bug 242153) as soon as possible, as every bug related to the grammars may be influenced by its resolution. I'll probably have a lot of time the next week to work on Eclipse-related tasks, so I plan to get some conclusion by the end of the next week.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 21, 2009 11:26

NB OMG Issue 8917 has some subtle wording explaining why allInstances is invoked with '.' rather than '::'. Use this as a JUnit test case source.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 21, 2009 11:57

Also OMG Issue 8937.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 28, 2009 09:15

Created attachment 145932 Support for static definition constraints

Attached uses UMLReflection to support static definition constraints.

A non-default ParsingOptions allows use of static to be treated as an error by the analyzer.

Use on the Ecore bindings generates an error message.

Since I had to add setIsStatic to UMLReflection I also added two irritating omissions: isConstraint() and isPackage(); not needed by this patch but needed elsewhere.

:notepad_spiral: StaticFeatures.patch

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Aug 31, 2009 05:15

Minor correction required to patch; I didn't understand Christian's ParsingOptions design.

ParsingOptions defines a static final default capability.

An option is tested by ParsingOptions.getValue(env, option);

An option is set by ParsingOptions.setOption(env, value);

The patch incorrectly tests and zaps the not-final ParsingOptions 'constant'.

eclipse-ocl-bot commented 1 month ago

By Adolfo Sanchez-Barbudo Herrera on Sep 02, 2009 11:49

Hi Ed,

It looks mostly nice. However some comments:

Just a question: what opinion do you have about the inclusion of some concepts in the OCLEcore metamodel, such us Constranit, SendSignalAction, etc ?

Cheers,\ Adolfo.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 02, 2009 14:45

Adolfo: is that a +1?

setStatic like isStatic requires the caller to be sensible about calling context. setStatic has a boolean return that gives some clue about validity. setStatic is only invoked from the analyzer where the argument is known to be a feature. (Unfortunately the generic lists are not long enough, there is no F for feature to allow a struct type.)

My comment #7 made the same point about wrong ParsingOptions usage.

The internal packages were only used by the emf.ocl tests so became obsolete. Christian's tests never validated message content so tests didn't need access to messages; now they do.

I've been considering raising an EMF request for a transition from a stylised EAnnotation to a first class EConstraint. I'm not convinced that making OCLEcore more compatible with OCLUML is sensible or possible.

eclipse-ocl-bot commented 1 month ago

By Adolfo Sanchez-Barbudo Herrera on Sep 03, 2009 09:46

(In reply to comment #9)

Adolfo: is that a +1?

Yes, after considering my suggestions.\

setStatic like isStatic requires the caller to be sensible about calling context. setStatic has a boolean return that gives some clue about validity. setStatic is only invoked from the analyzer where the argument is known to be a feature. (Unfortunately the generic lists are not long enough, there is no F for feature to allow a struct type.)

It's ok to me.

My comment #7 made the same point about wrong ParsingOptions usage.

Your comment suggests using the static ParsingOption value. I recall using the options of the Environment. Actually, your test cases doesn't set the parsing option in the environment.

Thinking a little more about this. Are this option really needed ?. Since this a feature of the new OCL spec, and this is a patch for the new MDT-OCL 3.0.0. Why is the reason of disallowing its use ?

Cheers,\ Adolfo.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 04, 2009 04:25

Committed to HEAD.

The parsing option is there defaulted to true to reflect the attempt at OCL 2.1, buit if someone wants 2.0, where possible I think we should help.

eclipse-ocl-bot commented 1 month ago

By Adolfo Sanchez-Barbudo Herrera on Sep 04, 2009 05:33

(In reply to comment #11)

Committed to HEAD.

The parsing option is there defaulted to true to reflect the attempt at OCL 2.1, buit if someone wants 2.0, where possible I think we should help.

Since 3.0.0. will be an OCL 2.1+ implementation, I don't even find necessary thinking about adding options to support. In other case we will have an innumerable amount of options + if-then-else along the code, which we wanted to avoid when deciding on MDT 3.0.0.

In any case, this kind of option makes sense to keep backwards compatibility, IMO. Since "static" was not supported in OCL 2.0 an ocl expression contraint won't have anyone, so I don't find necessary the need of changing this option default value, unless I want use MDT-OCL 3.0.0 to write new contraints for OCL 2.0 to be warned of using an OCL 2.1+ new feature?. Which is the mission of MDT-OCL 1.4.0 then ? Just for the lazy dependent projects ?

The parsing options has been a helping tool as a useful mechanism to include new features or make some non-API-breaker corrections while maintaining backwards compatiblity. I think we should reduce the options as fas as possible. We will have time to use them when doing 3.1.0, 3.2.0 etc.

I agree that allowing users to use the featured MDT-OCL 3.0.0 having OCL 2.0 in the background is good. However, we should also take advantage from the new major release increment to simply APIs, clean code and such. We could have a balanced compromise on this. But in this case, I guess that an user who has OCL 2.0 in the background, it won't use "static" keyword in its constraints.

P.S: I think it's better to have the complete patch, which has been comitted, attached to avoid confussions about what has been committed and what hasn't.\ P.S2: Adding the remaining team mate.

Cheers,\ Adolfo.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 05, 2009 02:22

If the team don't want the ParsingOption, we can easily eliminate it.

I'm not sure that you are being entirely consistent.

You agree that nothing much changes on the 1.4.x path since that is just a lifeboat for hopefully very few people who must preserve 1.3.x API and associated OCL compatibility. We are not even committing rather obvious fixes that just clean up the warnings. 1.4.x is about API compatibility not OMG version compatibility.

So in practice active OCL users have only 3.0.x. In so far as there are two reasonable and distinct dialects of OCL 2.x we should try to support them. Clearly this is very difficult while 1.3.x anticipated many 2.1 changes as the only sensible resolution of ambiguities. Now we find that we have to rely on Issues perhaps adopted for 2.3 to resolve 2.1 ambiguities and further overlooked 2.0 ambiguities.

It is not possible to produce a 2.1 or 2.0 compliant product; just a responsible endeavour.

Support for 'static' is one of the few 2.0/2.1 distinctions whose semantics is clear in 2.0 and 2.1 so we can support it.

eclipse-ocl-bot commented 1 month ago

By Adolfo Sanchez-Barbudo Herrera on Sep 05, 2009 13:35

(In reply to comment #13)

If the team don't want the ParsingOption, we can easily eliminate it.

As I said. ParsingOption is a good tool. I'm not saying that I want to eliminate it. For example, if we saw any kind of problem with a feature of OCL 2.1, or we need to include someone issued to OMG, which could be included in a future release, then we could use this options. What I wouldn't like is having a lot of options to set in MDT-OCL after a major release increament.

I'm not sure that you are being entirely consistent.

You agree that nothing much changes on the 1.4.x path since that is just a lifeboat for hopefully very few people who must preserve 1.3.x API and associated OCL compatibility. We are not even committing rather obvious fixes that just clean up the warnings. 1.4.x is about API compatibility not OMG version compatibility.

And this is not consistent with ... ?

So in practice active OCL users have only 3.0.x. In so far as there are two reasonable and distinct dialects of OCL 2.x we should try to support them.

If I'm not wrong the options were:

  1. Having an MDT-OCL 1.4.0 to keep API compatibility and support to the non-strict-with-failures OCL 2.0. Having an MDT-OCL 3.0.0 which we could freely make changes as we are able to break API, which would support the new OCL 2.1
  2. Just having an MDT-OCL version, which is able to cope both standards, with a lot of options in preferences page, etc. which was discarded in favour of the previous one.

As far as I understand, Are we adopting a third option which mixes both of them?. Having an MDT-OCL 1.4.0 to keep API compatibility and support the non-strict-with-failures of OCL 2.0. and a MDT-OCL 3.0.0 version which is able to cope both standards ?.

I see now where I wasn't consistent. Although, I see the power and flexibibility of giving the possibility to a final user to configure what features of the OCL 2.0 or OCL 2.1 what to use, this leads us to:

  1. Making us think in two standards instead of one.
  2. Making us think in unnecessary designs to support both standards.
  3. Making us carry on unnecessary design decisions/old API, etc to be able to support OCL 2.0. Are we carrying on those ElementType, TypeType, in MDT-OCL 3.0.0 etc ?

So in order to be consistent, I retract my words. I think that we shouldn't get a balanced compromise on facilitating OCL 2.0 backward compatibilty and cleaning API. We should definitely discard the former in favour of the latter, so that for instance any parsing option would include modifying any inconsistent feature of the OCL 2.1, but in any case adding unnecessary OCL 2.0 backward compatibility.

Clearly this is very difficult while 1.3.x anticipated many 2.1 changes as the only sensible resolution of ambiguities. Now we find that we have to rely on Issues perhaps adopted for 2.3 to resolve 2.1 ambiguities and further overlooked 2.0 ambiguities.

That is. Let's focus on OCL 2.1 and forget OCL 2.0, and if we need change something to make the implementation be more sensible, let's do it via configurable options or whatever, if possible.

It is not possible to produce a 2.1 or 2.0 compliant product; just a responsible endeavour.

Support for 'static' is one of the few 2.0/2.1 distinctions whose semantics is clear in 2.0 and 2.1 so we can support it.

As I have concluded, the endeavour should be lead to have the best design to support OCL 2.1 which include simplifying any winding design/API specifically introdoced by previous releases, which had a different requirement and which we don't fortunately have: backwards compatiblity.

That's my humble opinion, but I'm only a quarter of the cake.

Cheers,\ Adolfo.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Sep 25, 2009 01:23

Should have been marked Resolved at comment #11.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on May 27, 2011 02:47

Closing after over 18 months in resolved state.