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

Yes we agree. I hope to get something cool in pharo but in the future On Jul 2, 2008, at 10:46 AM, Toon Verwaest wrote: > I think slots are conceptually what you want, and indeed optimally > this > should probably be compiled away. > > In a nice reflective language it would be cool to also have the power > over your slots. How this gets optimized should not be visible to the > user. However, for a project like moose which has to run optimally at > this very moment I can only agree that it would be better to not use > non-optimized first-class slots. > > stephane ducasse wrote: >> 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." >>> >>> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev