Open eclipse-ocl-bot opened 2 months ago
By Ed Willink on Dec 18, 2021 11:04
The absence of an adequate specification leaves the source of static features unclear.
It could be null, minimal but requiring every feature access to handle the non-null source.
It could be a gratuitous TypeExp, ensuring that the source is non-null and many WFRs just work.
Philosophically, the Pivot is normalized and so as 'simple' as possible. The gratuitous TypeExp is simpler. But to support accurate round-trip serialization a TypeExp.isImplicit is needed.
By Ed Willink on Dec 18, 2021 11:06
(In reply to Ed Willink from comment #1)
It could be a gratuitous TypeExp, ensuring that the source is non-null and many WFRs just work.
No. https://issues.omg.org/browse/OCL25-221 and Bug 577887 conclude tht a static feture is one that needs no source and so logically should have no source. Therefore null.
By Ed Willink on May 04, 2022 07:46
(In reply to Ed Willink from comment #2)
No. https://issues.omg.org/browse/OCL25-221 and Bug 577887 conclude tht a static feture is one that needs no source and so logically should have no source. Therefore null.
Certainly simpler, but if we go for a purer Smalltalk-like Object model, the static features should be regular features of the metaclass - so TypeExp.
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196710
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196711
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196713
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196714
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196712
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196715
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196717
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196718
Nov 09, 2022 08:17
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196719
Nov 09, 2022 08:18
New Gerrit change created: https://git.eclipse.org/r/c/ocl/org.eclipse.ocl/+/196721
| --- | --- | | Bugzilla Link | 534421 | | Status | NEW | | Importance | P3 normal | | Reported | May 07, 2018 04:45 EDT | | Modified | Nov 09, 2022 08:18 EDT | | Depends on | 578443 | | See also | 285771, 577887, 439603, 578199, 330090, 500519, 500520, 500521, 579830, Gerrit change 196710, Gerrit change 196711, Gerrit change 196713, Gerrit change 196714, Gerrit change 196712, Gerrit change 196715, Gerrit change 196717, Gerrit change 196718, Gerrit change 196719, Gerrit change 196721 | | Reporter | Ed Willink |
Description
https://www.eclipse.org/forums/index.php/m/1786556/#msg_1786556 raises the interesting challenge of a counting per-class ID for instances. Easily implemented in Java by a static set of live-IDs to count the next/guard against duplicates.
How can this be realized in OCLinEcore to avoid recomputing the Set on each lazy allocation?
UML and so Pivot OCL and OCLinEcore (but not EMF) supports static operations and features. Therefore given that OCL has a Map and a Set, the implementation should be 'easy'.
Just need the OCLinEcore CG to contrive to express the static requirements so that genmodel works.
a) raise an EMF Bug to add static Ecore support. IIRC it has already been WONTFIXed ... Yes see Bug 285771.
b) injecting static functionality into each *Impl.java is hard without requiring custom templates. lcating the static functionality in XXXTables.java may be more tractable.
The above is for CGed support. What about dynamic support? It could just work if the dynamic support recognises the 'static' operations and if the dynaic access to the 'static' features has a suitable emulation.