[Moose-dev] Re: famix and fame

[Adrian Kuhn]

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."