[Moose-dev] fm3 opposites

Hi, 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. #((( #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 #))) any ideas / comments? Does this seem right / clean? cheers, Toon