Ring - model infrastructure for Pharo
Locked
12
12
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 |
Ring-forMethodReference.pdf (44K)
Re: Ring - model infrastructure for Pharo
|
|
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> > > > > > > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
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 <[hidden email]> 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. |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
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 <[hidden email]> wrote:
|
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
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. |
Re: Ring - model infrastructure for Pharo
|
|
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 <[hidden email]> wrote:
|
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Yanni Chiu
>
> 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. |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Francisco Ortiz Peñaloza
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 <[hidden email]> 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. > > > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Yanni Chiu
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." |
Re: Ring - model infrastructure for Pharo
|
|
Hi, On 11 Dec 2010, at 12:24, Tudor Girba wrote:
I have an alternative #itsClass, but #parentClass is a good suggestion.
No version or time info is kept in stringVersion.. This name is completely wrong.
Like the idea..
A compilation process defined in Behavior is using it.. Maybe I will change it and remove #methodClassAssociation
Thanks :) |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> 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. >> >> >> > > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Yanni Chiu
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. > > |
Re: Ring - model infrastructure for Pharo
|
|
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. |
Re: Ring - model infrastructure for Pharo
|
|
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. > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
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 |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
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> > > > > > > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Stéphane Ducasse
On 12 December 2010 08:41, Stéphane Ducasse <[hidden email]> 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. > 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. |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Noury Bouraqadi-2
> 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> >> >> >> >> >> >> > > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Igor Stasenko
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 <[hidden email]> 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. > |
Re: Ring - model infrastructure for Pharo
|
|
In reply to this post by Veronica Isabel Uquillas Gomez
On Dec 10, 2010, at 2:33 PM, Veronica Isabel Uquillas Gomez wrote:
#stringVersionDefault has just one sender (#markMatchingClasses in SelectorBrowser). Do we need that? In general, #stringVersion in MethodReference seems to be strange... stringVersion: 'Class>>selector:' format why is there an iVar for this? Can't this just use the selector and class an build it? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |