Indeed, as far as I saw the FMMultivalueLink is nothing but a smarter
collection that also takes care of updating the opposites.
If for some reason we will not like it anymore, we will be able to
replace them with Collection, and the rest of the code should work
just the same. So, I do not see a problem with this.
On Oct 9, 2008, at 11:28 AM, Toon Verwaest wrote:
I assume this is the replacement for opposite slots by Adrian which
exactly -not- increase space used and decrease speed. It is put where
you would put a collection for your objects anyway (since its
multivalued) and where you use the API for collections on that object;
it automatically updates the other side. I don't see how you can
implement this more optimally.
Correct me if I'm wrong, it's Adrian's code, not mine.
Stéphane Ducasse wrote:
> what is FMMultivalueLink?
> parentClass: aType
> parentClass := FMMultivalueLink on: self
> update: #attributes
> from: self parentClass
> to: aType
> parentClass set: aType
> I'm probably too stupid to understand but let us try.
> I do not understand why at the metamodel level I need to have in the
> objects of the metametamodel.
> Long long time ago I did a stupid code generator that took a stupid
> and generated plain code for the metamodel. Why this is not like that
> with FAMIX30
> in the latest version?
> why do we trade space **and** speed for a meta stuff?
> So do I have to code a code generator?
> Or just replace all the FMMultivalueLink myself?
> I'm confused I thought that the new FAME was better.
Moose-dev mailing list
"Next time you see your life passing by, say 'hi' and get to know her."