[Moose-dev] Re: [Fame-dev] Re: famix and fame

Thanks for the explanation. For me slots are meta description that should be compiled away at compile time because they consume memory and speed. Now I was wondering about links why you could not generate code from them because fame is supporting code generation so whydo you still need an object at runtime. Is there a case where you need the link object to attahced to it properties that otherwise would look funny in the classes. Stef On Jul 2, 2008, at 2:03 AM, Adrian Kuhn wrote: > A word about addTo* methods and slots vs links > > Fame offers two implementations for properties. If you use links > instead of slots, you do not need addTo* methods because the > collection returned by a getter is "hot". As far I know the > current code generation uses slots, whereas the hand-written code > of FM3 uses links. > > So what is the difference? > > In short: slots implement the "end" of each property, where as > links model the "association" established by the property. For a > large project, as eg Moose, I personally suggest to use links > instead of slots! Why? > > Links are less code (not *slot method) > Links are less memory (not wrapper objects at 1-end) > Links are hot (add and remove on returned collection) > Links are more debuggable (no wrapper in the way) > > @Toon ... this is your call to arms, what are the advantages of > slots? :) > > But first a general issue, why slots or links at all? To > automatically update the opposite of an association. A half-only > established association is one of the worst bugs in a data-model, > it is, to say so, the blink dog of software engineering. Half of > the time it works, half of the time not. Hence we decided to make > associations a first-level citizen in Fame. > > Considering Library and Book as an example of a multivalued, ie > ( 1 : n ) property, an implementation using slots looks like this > > Library >> initialize > books := FMManySlot new > on: self; > oppInstVar: #library; > youself > Library >> books > <MSEProperty: #books type: Book opposite: #library> > <multivalued> > ^books values > Library >> books: allBooks > books set: allBooks > Libary >> booksSlot > ^books > Library >> addToBooks: aBook > aBook libary: self > Library >> removeFromBooks: aBook > aBook library: nil > > Book >> initialize > library := OneSlot new > owner: self; > oppInstVar: #books; > yourself. > Book >> library > <MSEProperty: #library type: Library opposite: #books> > ^library value > Book >> library: newLibrary > library set: newLibrary > Book >> librarySlot > ^library > > And code to add / remove a book to / from a library like > > aLibrary addToBooks: newBook > aLibrary removeFromBooks: aBook > > And an implementation using links looks like this > > Library >> initialize > books := FMMultivalueLink on: self opposite: #library > Library >> books > <MSEProperty: #books type: Book opposite: #library> > <multivalued> > ^books > Library >> books: allBooks > books value: allBooks > > Book >> initialize > library := nil > Book >> library > <MSEProperty: #library type: Library opposite: #books> > ^library > Book >> library: newLibrary > library := FMMultivalueLink on: self > update: #books > from: self library > to newLibrary > > And code to add / remove a book to / from a library like > > aLibrary books add: newBook > aLibrary books remove: aBook > > Please note, this is not a violation of the Law of Demeter, since > accessing the elements of a container class (ie collection) does > not account as "talking" in the sense of the law's "never talk to > strangers". > > As you can see, using links there is no special need for those > notorious add / remove methods. > > cheers, > AA > > >> Hi, >> >> Today, Toon and me worked on Fame and FAMIX in Squeak. We >> regenerated >> FAMIX and the results are: >> >> - Added addTo* like methods (for example, FAMIXClass>>addToMethods: >> aMethod). The reason why it's not just addMethod: is due to us being >> unable tofind a simple and robust algorithm for producing English >> singular. Also, just taking the type into account is not enough >> because of cases like incomingInvocations and outgoingInvocations. >> >> - Changed the names of parameters to reflect whether they are >> collections or not. >> >> - Made the Smalltalk superclass to be MooseEntity. >> >> >> We also worked on creating the meta-repository for FAMIX and we also >> have MSE files with FAMIX models loading. There still some work >> to be >> done to populate the MooseModel. >> >> I also fixed the loading error related to FMBookMock and fixed >> some . >> I will continue with working on the Moose Finder over the next days. >> >> Doru >> >> -- >> www.tudorgirba.com >> www.tudorgirba.com/blog >> >> "Value is always contextual." > >