19 Aug
2010
19 Aug
'10
2:11 p.m.
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?
19 Aug
19 Aug
2:33 p.m.
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
3:06 p.m.
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:
--
Simon
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5238
days inactive
5238
days old
2 comments
3 participants
participants (3)
-
Cyrille Delaunay -
Simon Denier -
Tudor Girba