[Moose-dev] Re: About classVar in presence of metaclass /class merging

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