eclipse-ocl-bot
commented
1 month ago By Ed Willink on Jun 03, 2016 10:56
I don't think that the warning is wrong, however it can be irritating. In this case we need some form of
@suppressWarnings("shadow")
to silence them. Irritating warnings are an increasingly common theme as we produce more helpful dioagnosis. Just need a syntax.
New keyword is nasty. New punctuation is dangerous wrt extensions. ? idiomatic comment: ---keyword or --+keyword
... ---warning shadow
applies to all tokens preceding it on the line.
| --- | --- | | Bugzilla Link | 495376 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 03, 2016 06:52 EDT | | Modified | Jun 03, 2016 10:56 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |
Description
When declaring CS2AS descriptions, there are benefits (e.g in terms of conciseness) when declaring computation of container properties in a corresponding shadow expression. Not every single container property (opposite of a containment property) is always present in a meta-model. However, OCL allows you to use implicit opposites in such cases. For instance, to declare a mapping for an invariant (e.g. in MiniOCL), we could do the following:
context InvariantCS\ def : ast() : as::Constraint[1] =\ as::Constraint {\ name = 'Constraint',\ ownedSpecification = as::ExpressionInOCL {\ ownedBody = self.exp.ast(),\ ownedSelfVar = as::Variable{name='self', type= ast().Class}\ }, \ Class = ast().lookupClass(oclContainer().oclAsType(ConstraintsDefCS).typeRef)\ }
Fortunately, this warning does not compromise further CS2AS infrastructure generation, which demonstrates that the reasoning about the warning, should be revisited.
[NB the CG error I mentioned yesterday, has been cured when using the proper RHS expression. Therefore, I don't need this bugzilla to be fixed in short term.]
[NB2 current asanchez/miniocl includes the mapping, although it is currently commented in order not to interfer other work I'm doing]