Hi guys
I checked and found that
AbstractImporter>>errorLog: is deprecated.... ok fair
Now there are at least 4 methods that invoke this method and are not
deprecated.
So what do we do?
How do we log error in moose?
We don't?
Stef
When I have a Slot for example in methods of FAMIXType
methods: aMethod
methods set: aMethod
I do not understand that method.
methods: would need a collections?
So why do I get only aMethod
is set: an adder?
How should I add to methods?
addMethod: aMethod
methods add: aMethod
but in that case this is not aMethod I get above.
Of course beside reading the code of Slot and guessing there is
nothing I can do.
I'm not programming, I'm crawling.
Stef
Hi all
here are my plans for the coming 6 months.
- have a moose squeaking version based on FAMIX3.0
- introduce FAMIX30 based on meta on VW
- fix VW broken tests (yes), add class comments
rename classes, ...
If some people care they can join.
Hi
I'm fixing some parts of moose and I would like to learn where I can
find the information
about how to publish correctly (what are the conventions).
Stef
Hi
I'm working in 7.6 and I have problems to execute the moose tests.
How do you get the buttons?
I have RBSUnitExtension loaded.... but no effect
Stef
I'm wondering why a Method does not have a static/instance attribute.
In Famix2.1 we had
hasClassScope: aBoolean
self privateState attributeSet: #hasClassScope value: aBoolean
Now I do not like to see that as Smalltalk specific since the
distinction instance class is quite general enough
if we map hasClassScope to isStatic?
Stef
I'm contemplating morbidly Meta and I was wondering why do we need to
have EMOF
for what we do at the meta-metamodel. It seems to me that we lost our
soul in the process
and especially now that nobody maintain the metapart. I have large
doubts.
I run the test of meta dn 59 are breaking ;(
I'm considering porting FAMIX2.1 to Squeak. I will call the class
FAMIX2Class.
Stef
debugging with slot is not really cool since we get FMSlot everywhere
instead of the reference to the exact object.
Then I was wondering what is the exact gain: we do not duplicate the
management of what exactly?
Because we are trading coding the management of the relation by space
(the slot objects) and speed
we send value all the times everywhere now.
May be for FAME it is better to generate Slot instead of methods in
the class. But so far I do not know exactly what is the gain.
because I still have to define add/remove.... in the interface of the
class that has a slot.
It seems to me that this is meta programming for the poor. Ideally
Smalltalk would have a nice meta
object protocol and we would define a Slot metaobject and say it in
the class and we would get
the management at runtime or may be at compile time.
Now it looks to me like an overhead without any real gain.
Stef
doru
I wonder why there is a
FAMIXMethod>>initialize
initialize super initialize.
parentClass := FMOneSlot new
owner: self;
oppInstVar: #methods;
yourself.
and why there is the following definition in FamixType
initialize
super initialize.
subInheritances := FMManySlot new
owner: self;
oppInstVar: #superclass;
yourself.
methods := FMManySlot new
owner: self;
oppInstVar: #parentClass;
yourself.
container := FMOneSlot new
owner: self;
oppInstVar: #types;
yourself.
superInheritances := FMManySlot new
owner: self;
oppInstVar: #subclass;
yourself.
attributes := FMManySlot new
owner: self;
oppInstVar: #parentClass;
yourself.
do we have to do it because we do not specify in the Slot the type of
the target oppInstVar class?
Stef