12 Oct
2008
12 Oct
'08
10:09 p.m.
Now I learned that
TheRoot classVarNames ~= TheRoot class classVarNames
which I found ugly.
Stef
On Oct 12, 2008, at 10:04 PM, Stéphane Ducasse wrote:
Not really in fact I have to duplicate the knowledge
between the class
and the metaclass.
Because when I'm importing a class method that refers to a
classVariable the class variable had to be
in scope.... so I have to think because I thought I could do that
easily but I doubt now.
So even when we are not merging class and meta this is not simple. Or
this is me that is confused.
What is boring is that I did that already when I rewrote moose in
1998. And now redoing with different
constraints is boring.
Stef
On Oct 9, 2008, at 11:13 PM, Tudor Girba wrote:
Ah yes. It means that we just need a collection
for class variables.
Did I get it right now? :)
Cheers,
Doru
On Oct 9, 2008, at 9:19 PM, Stéphane Ducasse wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
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
>> Famix20?
>> Famix30?
There is no solution yet. I would say isShared is a good solution.
Ok I will implement that
>> 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.
Why should it break?
I checked and the ensure* attribute should be storing a name
(for
method, class, namespace, package we can use object in the hashtable
but not for stff like attribte since they are not runtime objects.
ensureAttribute: name for: aClass
^(self scopeOfClass: aClass)
at: name
ifAbsent:
[self
createAttribute: name
for: aClass]
so I may ask for a class instance variable and get an instance
variable and vice versa. For ClassVar this is not a problem since
they
should be uppercased.
Then this is just that if I query the uniqueInstance class instance
var and that the class side
You should not depend on names when storing the
variables anymore. As for looking the variable or method up
afterwards, you know at all times if you are looking on the class
or
on the instance side, so you can always ask it specifically.
Or?
do you see my point?
Stef
Doru
>> So I could modify the importer to have another mapping and let
>> in
>> the
>> resulting model
>> 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
>> implement.
>>
>> Stef
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"If you interrupt the barber while he is cutting your hair, you
will
end up with a messy haircut."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev