Hi all
I'm fixing the classVar/sharedVar import in SqMoose and after I will do it in VW. Now I have a question: when we make the distinction between a class and its metaclass this is easy.
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?
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. 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
Can somebody reply or really nobody care even to participate to the discussion?
Stef
On Sep 27, 2008, at 5:46 PM, stephane ducasse wrote:
Hi all
I'm fixing the classVar/sharedVar import in SqMoose and after I will do it in VW. Now I have a question: when we make the distinction between a class and its metaclass this is easy.
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?
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. 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
I'm fixing the classVar/sharedVar import in SqMoose and after I will do it in VW. Now I have a question: when we make the distinction between a class and its metaclass this is easy.
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.
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? 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?
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
On Oct 9, 2008, at 11:13 PM, Tudor Girba wrote:
Ah yes. It means that we just need a collection for class variables.
could be for the importer logic. I would have another collection in which class inst and classVar are put.
Now what do we want self model attributes entityNamed: (aClass mooseName@#iv)
Now if iv is an instance var and is also a class inst var and we merge the class and metaclass I will never be able to access it. So I proposed to change the name of class inst var when class and metaclass are merged
Stef
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
stephane ducasse -
Stéphane Ducasse -
Tudor Girba