12 Jun
2008
12 Jun
'08
10:08 p.m.
Ok I checked the code and there is no magical invocation involved so
this looks ok.
I'm just a bit pissed off that nothing is that transparent and
learning everything while porting it
is terrible for me.
stef
On Jun 12, 2008, at 9:53 PM, Tudor Girba wrote:
Slot is not meta-level. It's just an
implementation of Slots at
Smalltalk level.
For example, in FAMIXClass>>initialize you get:
methods := FMManySlot new
owner: self;
oppInstVar: #parentClass;
yourself.
Which will take care to populate the parentClass instance variable
when you add a method. In any case, you can just treat it as a
collection and everything should work just fine.
Perhaps, this is not necessarily needed, but I would say we could give
it a try.
Slots are not Fame specific. They just happen to be packaged in Fame.
But as Moose already depends on Fame, I think this dependency is not
really a problem.
Doru
On Jun 12, 2008, at 9:46 PM, Stéphane Ducasse wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Indeed, Slots are implemented in Fame, and the
CodeGenerator uses
that
instead of direct references or collections. That is why FAMIX uses
Slots.
But a Slot is at the metalevel?
Does it generate code at the FAMIX class implementation level?
Why cant we simply generate the code and get done?
Why do we want to have to have such dependency with Fame?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev