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