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.