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."
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."
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: aBookAnd 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: aBookPlease 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."
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
See also
http://www.cincomsmalltalk.com/userblogs/travis/blogView? entry=3373903413
cheers, AA
On 2 Jul 2008, at 12:03 , Stéphane Ducasse wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Dear Moosers,
I wanted to let you know about the new version of CodeCity, which you can download from here: http://www.inf.unisi.ch/phd/wettel/codecity-download.html
Release 1.2 (2.07.2008) adds the disharmony maps feature, some 3D layouts, and some new view configurations; it also brings massive improvements of the user interface. It also support opening the MooseBrowser from within CodeCity and keeps the model list in the CodeCity launcher in sync with the one in the Moose Browser. For a more detailed description, read the release history: http://www.inf.unisi.ch/phd/wettel/codecity-download.html#history
If you like it, let me know. If you don't like it, let me know.
Cheers, Ricky
P.S. If you would like to be updated about CodeCity, to report bugs, or to ask any questions about it, there is a mailing list that you can enroll on: http://lists.inf.unisi.ch/mailman/listinfo/codecity
Excellent! :)
Doru
On Jul 3, 2008, at 12:51 PM, Richard Wettel wrote:
Dear Moosers,
I wanted to let you know about the new version of CodeCity, which you can download from here: http://www.inf.unisi.ch/phd/wettel/codecity-download.html
Release 1.2 (2.07.2008) adds the disharmony maps feature, some 3D layouts, and some new view configurations; it also brings massive improvements of the user interface. It also support opening the MooseBrowser from within CodeCity and keeps the model list in the CodeCity launcher in sync with the one in the Moose Browser. For a more detailed description, read the release history: http://www.inf.unisi.ch/phd/wettel/codecity-download.html#history
If you like it, let me know. If you don't like it, let me know.
Cheers, Ricky
P.S. If you would like to be updated about CodeCity, to report bugs, or to ask any questions about it, there is a mailing list that you can enroll on: http://lists.inf.unisi.ch/mailman/listinfo/codecity
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"To lead is not to demand things, it is to make them happen."
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."
-
Adrian Kuhn -
Richard Wettel -
stephane ducasse -
Stéphane Ducasse -
Toon Verwaest -
Tudor Girba