If you do so, please use named references not Strings
(FM3.Package (name 'P') (classes (FM3.Class (name 'A') (attributes (FM3.Property (name 'foo') (opposite (ref: P.B.bar))))) (FM3.Class (name 'B') (attributes (FM3.Property (name 'bar') (opposite (ref: P.A.foo)))))))
Also for superclass links etc would be nice to have named references, I'd suggest that we should allow named references there as well.
cheers, AA
On 27 Nov 2007, at 20:05 , Toon Verwaest wrote:
Then at some point I might put in that opposite/derived/type story I told Adrian and Doru; if I am working on this anyway. For those who are not following and still reading (you must be really bored :P)
(... (name "type1") (property (name "prop1") (derived true) (type "type2") (opp "prop2") ....)
(... (name "type2") (property (name "prop2") (type "type1") (opp "prop1") ....)
has duplicated info and could be reduced to: (... (name "type1") (property (name "prop1") (type "type2") (opp "prop2") ....)
(... (name "type2") (property (name "prop2") ....)
-> if you link to a prop of another type; that prop of that other type automatically links back to you (prop) with as type, the class in which that prop was defined. The one stating the opposite link is automatically the derived version. 1 special case: if a prop has itself as opposite (i.e. the opposite property of FM3.Property), it is not derived.
This comes from the fact that while defining the original drafts for FAMIX3.0, I had to type out this info. And having to copy all that data over and over again... is quite a hassle. And well, duplicated info is never good anyway.