#(((#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?
Not yet, shouldn't be too difficult though...
I just had a look at this, and it actually already automatically works, since opposites are defined as One instances of my implementation of One to One relations; since they have an opposite. When you write one of the opposites; the other one is automatically set. (I don't set the types automatically yet; but that should only be two lines of code)
Writing this out to an MSE file with only one opposite also doesn't work yet; since my derived-flag (which is chosen automatically; the first property with an opposite that comes will be written; the other site is automatically the derived one) of an opposite attribute is stored in the opposite attribute itself; and since "opposite"(the opposite attribute of the FM3.Property) is its own opposite attribute; this would stop the writer from writing anything. But since this is a one to one; for this case I could instead of saving it in the opposite attribute; just keep a list of instances which are derived; instead of descriptions which are derived.
I hope that the text with the opposites is not -too- confusing :)
Toon