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