[Pharo-project] Ring - model infrastructure for Pharo
Dear all, I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). Best Regards, Veronica Uquillas
Thanks veronica I hope that people will react and yes having a nice API for most of the tools is important. Stef
Dear all,
I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
Best Regards, Veronica Uquillas
<Ring-forMethodReference.pdf>
WoW. That's quite ambitious project and will require the huge overhaul of existing code. I really hope that you will succeed with it. Do not hesitate asking for help of advice. I will try to comment proposal a bit later. On 10 December 2010 14:32, Veronica Isabel Uquillas Gomez <vuquilla@vub.ac.be> wrote:
Dear all, I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
Best Regards, Veronica Uquillas
-- Best regards, Igor Stasenko AKA sig.
Hi.. Ring will be good improvement.. Thank for you effort But some comments about your propousal (i may be wrong in some concepts but, may be this commets will be a guide ) classSymbol vs className, in y opnion classSymbol define better because this message return a Symbol.. in case className I would expect for this message return a String sourceString and sourceCode in some case can be different,,in most cases are the same category may by usefful. i'm use this by example for iterate on the accessors Best Regards On Fri, Dec 10, 2010 at 10:32 AM, Veronica Isabel Uquillas Gomez < vuquilla@vub.ac.be> wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
Best Regards, Veronica Uquillas
On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names. Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like. The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta. classSymbol --> className - yes methodSymbol --> selector - yes sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used. source --> formattedSource - yes stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name I don't understand the talk about methodClass, objectClass, variableClass, commentClass. Hope that helps.
hi, i really like the idea, quite a challenge :) But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix. Regards, Francisco On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
Hope that helps.
On Dec 11, 2010, at 6:47 AM, Francisco Ortiz Peñaloza wrote:
hi, i really like the idea, quite a challenge :)
But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix.
what is the alternative? class? No it does not work (Point>>#x) class -> CompiledMethod and we want (Point>>#x) theClass -> Point (Point>>#x) asMethodDefinition class -> MethodDefinition and we want (Point>>#x) asMethodDefinition theClass -> aClassDefinition for Point
Regards, Francisco
On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <yanni@rogers.com> wrote: On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
Hope that helps.
On 11 Dec 2010, at 10:33, Stéphane Ducasse wrote:
On Dec 11, 2010, at 6:47 AM, Francisco Ortiz Peñaloza wrote:
hi, i really like the idea, quite a challenge :)
But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix.
what is the alternative? class?
#itsClass #parentClass (suggested by Tudor)
No it does not work (Point>>#x) class -> CompiledMethod and we want (Point>>#x) theClass -> Point
(Point>>#x) asMethodDefinition class -> MethodDefinition and we want (Point>>#x) asMethodDefinition theClass -> aClassDefinition for Point
Regards, Francisco
On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <yanni@rogers.com> wrote: On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
Hope that helps.
On Sat, 11 Dec 2010 19:34:12 +0100, Veronica Isabel Uquillas Gomez <vuquilla@vub.ac.be> wrote:
On 11 Dec 2010, at 10:33, Stéphane Ducasse wrote:
On Dec 11, 2010, at 6:47 AM, Francisco Ortiz Peñaloza wrote:
hi, i really like the idea, quite a challenge :)
But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix.
what is the alternative? class?
#itsClass #parentClass (suggested by Tudor)
Create a new poor mans's selector namespace and call it #ringClass (or #RINGclass or #ring_class or #RING_class to highlight the namespace part of the selector more). This way you retain the advantage of the familiarity of an old name (#class) and avoid clashes, for the price of a some extra keyboarding. Cheers, Peter
No it does not work (Point>>#x) class -> CompiledMethod and we want (Point>>#x) theClass -> Point
(Point>>#x) asMethodDefinition class -> MethodDefinition and we want (Point>>#x) asMethodDefinition theClass -> aClassDefinition for Point
Hi peter
But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix.
what is the alternative? class?
#itsClass #parentClass (suggested by Tudor)
Create a new poor mans's selector namespace and call it #ringClass (or #RINGclass or #ring_class or #RING_class to highlight the namespace part of the selector more).
it does not work because we want to have also this method to return the runtime class.
This way you retain the advantage of the familiarity of an old name (#class) and avoid clashes, for the price of a some extra keyboarding.
Stef
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
the idea is that RING represents source code entities: methodDefinition, classDefinition, ... not the object actually running but to have an API that is the same for runtime and declarative entities so that all the tools can work on representation and runtime entities. Veronica is proposing (and I like that to have always a systematic way to accessible the entity) aMethodDefinition theClass versus aMethodDefinition actualClass for everybody But more important right now in CompiledMethod we have compiledMethod>>methodClass this convention is not really good since we do not have a polymorphic message: following this pattern we would end up with methodClass, variableClass, packageClass and we would have to always test so she propose to have theClass aCompiledMethod theClass will return the class of the compiledMethod (Point>>#x:) theClass -> Point But also that aMethodDefinition theClass returns the Class represented by aMethodDefinition className And by convention aVariable theClass .... May be this is not 100% exact because I'm hurry but this is the idea: having a polymorphic way to access parent.
Hi, Nice initiative. I added my comments below. On 11 Dec 2010, at 04:17, Yanni Chiu wrote:
On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
I would suggest parentClass.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
In Moose we have isMetaSide / isInstanceSide.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
I also agree that sourceCode is better.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
#fullName implies that you will get a meaningful name, but the version is not part of the name. But, why do we actually need this stringVersion method? Why not have a #timestamp method instead, and then use that when you want to print the information?
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
I would rename is #methodClass to #parentClass. I would keep or rename the followings: #methodReference -> #reference #methodNode -> #node As for #methodClassAssociation:, I think it is better to keep it like it is, but my question is why do we actually need this ugly method. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."
Hi, On 11 Dec 2010, at 12:24, Tudor Girba wrote:
Hi,
Nice initiative. I added my comments below.
On 11 Dec 2010, at 04:17, Yanni Chiu wrote:
On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
I would suggest parentClass.
I have an alternative #itsClass, but #parentClass is a good suggestion.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
In Moose we have isMetaSide / isInstanceSide.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
I also agree that sourceCode is better.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
#fullName implies that you will get a meaningful name, but the version is not part of the name.
But, why do we actually need this stringVersion method? Why not have a #timestamp method instead, and then use that when you want to print the information?
No version or time info is kept in stringVersion.. This name is completely wrong.
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
I would rename is #methodClass to #parentClass. I would keep or rename the followings: #methodReference -> #reference #methodNode -> #node
Like the idea..
As for #methodClassAssociation:, I think it is better to keep it like it is, but my question is why do we actually need this ugly method.
A compilation process defined in Behavior is using it.. Maybe I will change it and remove #methodClassAssociation
Cheers, Doru
Thanks :)
-- www.tudorgirba.com
"Every thing has its own flow."
veronica
As for #methodClassAssociation:, I think it is better to keep it like it is, but my question is why do we actually need this ugly method.
If this is not in MethodReference we do not really care. Now if it is we should understand if it is called on MethodReference and why?
A compilation process defined in Behavior is using it.. Maybe I will change it and remove #methodClassAssociation
Cheers, Doru
Hi, this is valuable info... Thank you!! On 11 Dec 2010, at 04:17, Yanni Chiu wrote:
On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the *Ring*, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names.
Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like.
The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta.
classSymbol --> className - yes methodSymbol --> selector - yes
sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used.
source --> formattedSource - yes
stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name
I don't understand the talk about methodClass, objectClass, variableClass, commentClass.
Hope that helps.
CompiledMethod>>#methodNode is a conversion method and as any conversion i would prefer it be prefixed with 'as' , i.e. #asMethodNode #stringVersion is used only in MessageTrace in my image. Concerning #stringVersion: i really don't have an idea what this stuff doing there? Why a method reference allows putting an arbitrary data (strings) there by various tools? Then maybe better call it 'annotation' , and correspondingly #defaultAnnotation, so we will know that this field used for annotations by different tools? About #isMeta and friends: they serve nothing , but introducing a lot of ad-hoc logic with code branches all over the places. We should learn how to use message dispatching better :) IMO, the 'theClass' ivar should be capable answering this message, along with #name, which gives the name of a class. Method reference in its 'theClass' ivar instead of symbol, should hold either real class object (or metaclass object), or a proxy (in same way as method reference is a proxy by itself). -- Best regards, Igor Stasenko AKA sig.
On Dec 11, 2010, at 8:35 PM, Igor Stasenko wrote:
CompiledMethod>>#methodNode is a conversion method and as any conversion i would prefer it be prefixed with 'as' , i.e. #asMethodNode
#stringVersion is used only in MessageTrace in my image.
Concerning #stringVersion: i really don't have an idea what this stuff doing there? Why a method reference allows putting an arbitrary data (strings) there by various tools?
:) because it was handy and cool to have a holder of anything from the tools point of view. And this is why we will clean that :)
Then maybe better call it 'annotation' , and correspondingly #defaultAnnotation, so we will know that this field used for annotations by different tools?
About #isMeta and friends: they serve nothing , but introducing a lot of ad-hoc logic with code branches all over the places. We should learn how to use message dispatching better :)
this is not always that simple.
IMO, the 'theClass' ivar should be capable answering this message, along with #name, which gives the name of a class. Method reference in its 'theClass' ivar instead of symbol, should hold either real class object (or metaclass object),
No because you can be analysing an off-image code or not yet installed code. So you cannot rely on the fact that the real class is reachable.
or a proxy (in same way as method reference is a proxy by itself).
-- Best regards, Igor Stasenko AKA sig.
On 12 December 2010 08:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 11, 2010, at 8:35 PM, Igor Stasenko wrote:
CompiledMethod>>#methodNode is a conversion method and as any conversion i would prefer it be prefixed with 'as' , i.e. #asMethodNode
#stringVersion is used only in MessageTrace in my image.
Concerning #stringVersion: i really don't have an idea what this stuff doing there? Why a method reference allows putting an arbitrary data (strings) there by various tools?
:)
because it was handy and cool to have a holder of anything from the tools point of view. And this is why we will clean that :)
Then maybe better call it 'annotation' , and correspondingly #defaultAnnotation, so we will know that this field used for annotations by different tools?
About #isMeta and friends: they serve nothing , but introducing a lot of ad-hoc logic with code branches all over the places. We should learn how to use message dispatching better :)
this is not always that simple.
IMO, the 'theClass' ivar should be capable answering this message, along with #name, which gives the name of a class. Method reference in its 'theClass' ivar instead of symbol, should hold either real class object (or metaclass object),
No because you can be analysing an off-image code or not yet installed code. So you cannot rely on the fact that the real class is reachable.
i see no problem with offline representation. You still won't need 'isMeta' in method definition, because you have a following model: instance side method ref -> some class proxy class side method ref -> some metaclass proxy sure you can leave #isMeta in method reference which simply redirects the request to its 'theClass' variable: isMeta ^ theClass isMeta voila. A CompiledMethod makes no difference between class/metaclass, its only holds a reference to the behavior it installed in: method := (Object class>>#initialize). method methodClass ---> Object class method methodClass isMeta ---> true (Object class>>#initialize) methodClass name ---> 'Object class' So, since method references representing the CompiledMethod, they should not care as well.
or a proxy (in same way as method reference is a proxy by itself).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Yes Now this is the choice of veronica to know how many classes she wants because in addition to class/instance there is also compiledMethod methodDefinition.... Stef On Dec 12, 2010, at 1:47 PM, Igor Stasenko wrote:
On 12 December 2010 08:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 11, 2010, at 8:35 PM, Igor Stasenko wrote:
CompiledMethod>>#methodNode is a conversion method and as any conversion i would prefer it be prefixed with 'as' , i.e. #asMethodNode
#stringVersion is used only in MessageTrace in my image.
Concerning #stringVersion: i really don't have an idea what this stuff doing there? Why a method reference allows putting an arbitrary data (strings) there by various tools?
:)
because it was handy and cool to have a holder of anything from the tools point of view. And this is why we will clean that :)
Then maybe better call it 'annotation' , and correspondingly #defaultAnnotation, so we will know that this field used for annotations by different tools?
About #isMeta and friends: they serve nothing , but introducing a lot of ad-hoc logic with code branches all over the places. We should learn how to use message dispatching better :)
this is not always that simple.
IMO, the 'theClass' ivar should be capable answering this message, along with #name, which gives the name of a class. Method reference in its 'theClass' ivar instead of symbol, should hold either real class object (or metaclass object),
No because you can be analysing an off-image code or not yet installed code. So you cannot rely on the fact that the real class is reachable.
i see no problem with offline representation. You still won't need 'isMeta' in method definition, because you have a following model:
instance side method ref -> some class proxy class side method ref -> some metaclass proxy
sure you can leave #isMeta in method reference which simply redirects the request to its 'theClass' variable:
isMeta ^ theClass isMeta
voila.
A CompiledMethod makes no difference between class/metaclass, its only holds a reference to the behavior it installed in:
method := (Object class>>#initialize).
method methodClass ---> Object class method methodClass isMeta ---> true (Object class>>#initialize) methodClass name ---> 'Object class'
So, since method references representing the CompiledMethod, they should not care as well.
or a proxy (in same way as method reference is a proxy by itself).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
1 ring to rule all meta-models. Cool :-) I struggled with MC and its meta-model while working with on the Clic project. In Clic I changed the class definition message. But, MC does not support such situations. So, I ended up doing some complex workarounds. Hope that Ring will help solving such situations. Noury On 10 déc. 2010, at 14:32, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
Best Regards, Veronica Uquillas
<Ring-forMethodReference.pdf>
1 ring to rule all meta-models. Cool :-)
who told you :) You are the first one to guess for the name :) Stef
I struggled with MC and its meta-model while working with on the Clic project. In Clic I changed the class definition message. But, MC does not support such situations. So, I ended up doing some complex workarounds.
Hope that Ring will help solving such situations.
Noury On 10 déc. 2010, at 14:32, Veronica Isabel Uquillas Gomez wrote:
Dear all,
I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis
I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes.
An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file).
Best Regards, Veronica Uquillas
<Ring-forMethodReference.pdf>
participants (9)
-
Diogenes Moreira -
Francisco Ortiz Peñaloza -
Igor Stasenko -
Noury Bouraqadi -
Peter van Rooijen -
Stéphane Ducasse -
Tudor Girba -
Veronica Isabel Uquillas Gomez -
Yanni Chiu