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:
>
>>>>> 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
>
> --
>
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