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.
I'm fixing the classVar/sharedVar import in SqMoose and after I will
do it in VW.
Now I have a question:
when we make the distinction between a class and its metaclass this
when we merge a class and its metaclass:
a metaclass instVar will become a "class variable"
But we really need a way to make the distinction between a
sharedvariable and merged class inst var.
so I would like to have isShared in attribute or SmalltalkFamix
extension: how do I do that in
Then if I have the same variable name at the instance and class side
when I merge I have a conflict with name
and the importer will break.
So I could modify the importer to have another mapping and let in the
two attributes with the same name but different scope
or I could modify the name of the mapped class inst var with
something like CL-x (would means I was a class var
but I was merged). Of course this solution is uglier but easier to
I was reading
"Returns an unique identifier of this entity. This method is
mandatory, and must
return an Integer that unqiuely identifies this entity within the
entire Moose environ-
ment. The return value must not be nil, and must never change."
nil = mooseID ifTrue: [mooseID := MooseModel freshID].
and I wonder why this is MooseModel freshID
since freshID is only implemented on
I'm looking for the mse file describing FAMIX3.0 - I couldnt find it
on the moose website.
We want to load it with Fame VW and Fame for Java. Did anyone try that
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
I'm working on making shared variable available in sqmoose and I got
the following situation
When I import referenceModel
When I reify TheRoot (from referenceModel) the importer
create all the superclass up to protoobject and more..... Object
class, .... Behavior...
Just because it is importing recursively all the superclass chain.
For my point of view this is wrong. I'm quite sure that the old
importer did not go all the way up.
It was creating the superclass as a stub and stopped there.
I'm checking in VWoose to see what is the behavior but I propose to
fix it too
if this is not a squeakish behavior of the importer.
What do you think?