MooseGroups'concatenation - side effect
Locked
 
|
Hello,
I got some problems by concatenating some mooseGroups together. You can evaluate this script in a workspace (it correspond to what I did in my code): |mooseModel|
Transcript open. MooseScripts createLightModelForLAN. mooseModel := MooseModel root allModels detect: [:aMooseModel | aMooseModel name ='lightLAN']. "at the begening, all famixClasses from this model have methods"
Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. "here we do several concatenations with methods from all FAMIXClasses:"
mooseModel allModelClasses do: [:aFamixClass | aFamixClass methods , aFamixClass inheritedMethods ].
"let see the new result: " Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr.
You can see that after the concatenations, some FAMIXClasses have lost their methods. Is it a real problem or is it me that is missing something obvious?
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: MooseGroups'concatenation - side effect
|
|
Hi Cyrille,
The problem is not with MooseGroups but with the way you want to use FMMultivalueLink. These links have side effects to ensure that the opposite is maintained correctly when you set only one part of the relationship. However, the problem is that if you copy such a link object, you will get a copy of the collection, but the pointers to the owner and opposite is still the same, so you will have side effects due. I would suggest to work with these either through the groups or by converting to OrderedCollection. Instead of aClass methods, use either: - aClass methodsGroup - aClass methods asOrderedCollection Cheers, Doru On 19 Aug 2010, at 14:11, Cyrille Delaunay wrote: > Hello, > > I got some problems by concatenating some mooseGroups together. > You can evaluate this script in a workspace (it correspond to what I > did in my code): > > |mooseModel| > Transcript open. > MooseScripts createLightModelForLAN. > mooseModel := MooseModel root allModels detect: [:aMooseModel | > aMooseModel name ='lightLAN']. > > "at the begening, all famixClasses from this model have methods" > Transcript show: (mooseModel allModelClasses select: [:each | > each methods isEmpty]) size asString, String cr. > > "here we do several concatenations with methods from all > FAMIXClasses:" > mooseModel allModelClasses do: [:aFamixClass | > aFamixClass methods , aFamixClass inheritedMethods > ]. > > "let see the new result: " > Transcript show: (mooseModel allModelClasses select: [:each | > each methods isEmpty]) size asString, String cr. > > You can see that after the concatenations, some FAMIXClasses have > lost their methods. > Is it a real problem or is it me that is missing something obvious? > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Value is always contextual." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: MooseGroups'concatenation - side effect
|
|
On 19 août 2010, at 14:33, Tudor Girba wrote: > Hi Cyrille, > > The problem is not with MooseGroups but with the way you want to use FMMultivalueLink. These links have side effects to ensure that the opposite is maintained correctly when you set only one part of the relationship. However, the problem is that if you copy such a link object, you will get a copy of the collection, but the pointers to the owner and opposite is still the same, so you will have side effects due. > > I would suggest to work with these either through the groups or by converting to OrderedCollection. Instead of aClass methods, use either: > - aClass methodsGroup > - aClass methods asOrderedCollection In my opinion it's kind of a bug. We may hit it later (or we may already have it somewhere in the code) and we can't let users guess whether there are dealing with a MultiValue or a group/collection when dealing with such methods. The premise of an expression such as aFamixClass methods , aFamixClass inheritedMethods is that it works with a copy so it does not affect the original object. But FMMultivalueLink>>copy still returns a FMMultivalueLink, which still has side-effects. The basic message is be careful with FMMultivalueLink>>copy but what now? - we may override #copy to return an ordered collection, but it breaks the contract of #copy, or not? - we may check/override #, and similar methods (Collection methods which copy and call add:remove:) > > Cheers, > Doru > > > On 19 Aug 2010, at 14:11, Cyrille Delaunay wrote: > >> Hello, >> >> I got some problems by concatenating some mooseGroups together. >> You can evaluate this script in a workspace (it correspond to what I did in my code): >> >> |mooseModel| >> Transcript open. >> MooseScripts createLightModelForLAN. >> mooseModel := MooseModel root allModels detect: [:aMooseModel | aMooseModel name ='lightLAN']. >> >> "at the begening, all famixClasses from this model have methods" >> Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. >> >> "here we do several concatenations with methods from all FAMIXClasses:" >> mooseModel allModelClasses do: [:aFamixClass | >> aFamixClass methods , aFamixClass inheritedMethods >> ]. >> >> "let see the new result: " >> Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. >> >> You can see that after the concatenations, some FAMIXClasses have lost their methods. >> Is it a real problem or is it me that is missing something obvious? >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |