Hi all
I reintroduced flatCollect: fixing also collectUnion:
I deprecated collectUnion: and replaced all the occurence of
collectUnion: in mooseDevelopment and friends
let me know if this is ok for you.
Stef
Hi,
For an overview on presence/absence of class comments in Moose/Squeak see SqueakSource/PackageExplorer.
In order to fix absent class comments I'd need a minimal understanding of the design. A certain book called "object-oriented reengineering patterns" tells me - among other advices - to "skim the documentation". Can you give me a hint what to read on the architecture of MOOSE ?
cu
Pascal
----- Original Nachricht ----
Von: Stéphane Ducasse <stephane.ducasse(a)univ-savoie.fr>
An: Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch>
Datum: 23.06.2008 11:08
Betreff: [Moose-dev] Re: who can help
> Thanks pascal.
> Amy be we should create an account for you.
> making a list of the class that lack comments and fixing them would be
> good.
> Sorting also some tests: sometimes we have one class with one test
> would be good to.
> and help porting....
> Stef
>
>
> On Jun 23, 2008, at 12:12 AM, pascal.vollmer(a)nexgo.de wrote:
>
> > Hi,
> >
> > I am prepared to do jobs in the area of: qa, documentation, test,
> > statistical methods. I will be of limited use wrt coding since I
> > have small experience here (coming from C++ and diving into
> > Smalltalk since 2 years only.)
> > If this makes sense to you just drop a message what is the job you
> > would like to be done.
> >
> > cheers,
> > Pascal
> >
> >
> > ----- Original Nachricht ----
> > Von: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> > An: Related to the development of Moose and other related tools
> > <moose-dev(a)iam.unibe.ch>
> > Datum: 22.06.2008 12:29
> > Betreff: [Moose-dev] who can help
> >
> >> Hi
> >>
> >> I would like to who besides doru can really help in migrating Moose
> >> to
> >> Squeak and maintaining.
> >> Because so far I see only me alex and doru.
> >>
> >> Stef
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >
> > Pascal Vollmer
> > Email: pascal.vollmer(a)ieee.org
> >
> > Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends,
> > mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV
> > Programme und optional 60 Pay TV Sender, einen elektronischen
> > Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem,
> > aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos
> > unter www.arcor.de/tv
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
Pascal Vollmer
Email: pascal.vollmer(a)ieee.org
Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
Hi,
I stumble (again) into the same problem.
When importing from an MSE file, I get a MNU exception for
#accessedByList on the FAMIXNamespace UNKNOWN_NAMESPACE.
Is this something you are aware of?
I run on top of the latest MooseDevelopment (loaded Moose Config).
Thanks,
Ricky
Hi,
How can I have a duplication of a mooseModel (for example the model
that represents Mondrian namespace)? exactly like if I imported agin
the namespace Mondrian:
there is no entity in the duplication that has pointers to entities in
the original model.
For example, the accesses of a method 'mtd1' into the duplication
should not point to classes into the original model.
bests,
hani
Hi,
I would know if there is a mean to only import in a MooseModel the selected
packages in the MooseBrowser?
For example, when I import the bundle Moose in Moose Browser, I would only
have in the MooseModel the packages of the bundle.
I hope it was clear.
Romain
let us imagine that we would like to see what would happen if we would
move
a class A from package P1 to P2, without changing the source code and
may be been able to undo the change
Solution A:
We could copy the complete model, modify it. (and keep somewhere an
history)
Solution B:
We could change the model and keep an history of the changes (move A
P1 P2).
Solution C: I could cache in each model a timestamp similar to what
frederic pluquet did
and know at which version modification we are. then for a given
changes I could get the model by getting entity at the same level or
lower.
Any thoughts on that.
I have the impression that solution B is easier.
stef
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."