eclipse-qvtd-bot
commented
1 week ago By Ed Willink on Feb 21, 2017 15:55
Consider a real world example:\ abstract class Child { name : String }\ class Boy extends Child;\ class Girl extends Child;\ key Child{name};\ mapping newBoy(name) => Boy{name};\ mapping newGirl(name) => Girl{name};\ the key enforces the sensible practice that all children in a family have distinct names. But the example is nonsense. Following newGirl("alex"), newBoy("alex") returns the previous girl; tears and lawsuits in the maternity department. The key is a good practice, not a necessity.
Consider another example where uniqueness may be genuine.\ abstract class NationalDocument{ id : String }\ class DrivingLicense extends NationalDocument{ name : String };\ class Passport extends NationalDocument{ name : String };\ key NationalDocument{id};\ mapping newDrivingLicense(name,id) => DrivingLicense{name,id};\ mapping newPassport(name,id) => Passport{name,id};\ but there will just be chaos if the DrivingLicense::id and Passport::id are not orthogonal. The key could be justified, but only with an associated discipline. Two keys would be more sensible.
"key A(b,c)" used by "a = :A{b=b,c=c}" is syntax sugar for something like "when { KeyA(b,c,a); }" used by "a = a"
the expansion defines no polymorphism, but could be elaborated for more interesting requirements.
Conclusion: keys do not apply to derived types and so cannot be used for abstract types.
Conversely, if they did, many uses of a derived key class would have to diagnose a type hazard that the re-used object might be type incompatible.
| --- | --- | | Bugzilla Link | 512532 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 21, 2017 14:52 EDT | | Modified | Jun 29, 2019 03:21 EDT | | Blocks | 512734, 515236 | | See also | 516223, 530991, 548536, 548757 | | Reporter | Ed Willink |
Description
The spec is vague on how inheritance and keys interact.
Consider the A(b,c) key.
If we need to 'create' a derived-A(b,c) when an A(b,c) exists, A may not be a derived-A, so the A(b,c) key cannot apply to derived-A. But surely it should? If we create a derived-A(b,c) then we have two A(b,c). Is it an error?
If we need to 'create' an A(b,c) and a derived-A(b,c) exists, do we use the derived-A?
??? No its normal. If we want a static A, then we use only the static A key, for which a derived-A may be available, but we only use a static A so the derivation is fine. Creating an A key instance may also create a super-A key instance.
But we don't specify that we want a static A; we specify that we want a derived-A and the A-uniqueness may deliver a different derived-A.
What are the WFRs relating derived-A(b,c,d) and A(b,c)? Surely a pure sub-set so that some A(b,c) are also derived-A(b,c,d). Vice-versa, no derived-A(b,c,d) is not a A(b,c).
Derived keys must be orthogonal to avoid duplicate base instances.
Can A be abstract? Yes.
[Resolved elsewhere: there cannot be overlapping partial keys: A(b,c)+A(b,d) => A(b,c,d)]