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

[Adrian Kuhn]

Current code generation uses slots because Toon prefers them :)
Best would be to have two subclasses of FMDomainCodeGenerator and  
then either generate code for slots or links. Or even better . Should  
be quite-straight forward to do that.

cheers,
AA

On 2 Jul 2008, at 8:36 , 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."
>>
>>