7 Dec
2007
7 Dec
'07
7:07 p.m.
On 7 Dec 2007, at 15:51 , Toon Verwaest wrote:
currently opposites are described as
opposite and opposite+derived. This can be one->one, one->many,
many->one and many->many. We
can easily generate code which handles all those different cases.
Secondly, when we are writing out instances of fm3-described
classes; we
know when attributes
have an opposite. There the derived is quite unimportant; since it is
just a hint to the writer "which" of
the 2 opposites it should write and which it should derive. However,
since you can
generate code which takes all different cases into account, writing it
out (and reading it in) either way is
possible. The opposite can be filled in from either of the available
relationships. So which opposite you
file out could be chosen randomly. Coming to my point: do attributes
which have an opposite need a
derived statement? Isn't it more logical that only real algorithmic
"attributes" are derived? When choosing
automatically you will only have to take care that if an opposite
is its
own opposite (the opposite of the
attribute "opposite" in fm3.Property is like this; that's probably the
only case :)), that it always gets written.
You are right, the derived opposites are a mere hint. Some points why
this might nevertheless be a good idea to keep them, we are not the
only client of mse
- generated code is not the only use-case
- there is legacy code that does not update opposites automatically
- some people use hardcoded mse exporters
- some people use hardcoded mse importers
#(((#This fact would again strengthen my case that the
opposite of an
opposite should not necessarily be
#declared as an opposite in the MSE file. Nor should the type be in
either of them. If we find (prop (id: 2)
#(opposite (idref: 1))), then we should automatically do (objectAtId:
1).setOpposite(objectAtId: 2),
#which sets the owner of (objectAtId: 2) as it's type, sets the
type of
the (objectAtId: 2) as the owner of
#(objectAtId: 1); and then sets (objectAtId: 2) as the opposite of
(objectAtId: 1)
#
#---->> if you use an opposite-declaration for an attribute; you
have 1
statement instead of 5 for which 4 are
#redundant ----> less redundancy => better performance
#)))
Do you have a reference implementation?
any ideas / comments? Does this seem right / clean?
cheers,
Toon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev