Ring - model infrastructure for Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ring - model infrastructure for Pharo

Veronica Isabel Uquillas Gomez
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) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Diogenes Moreira
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:
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










Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Yanni Chiu
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.


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Francisco Ortiz Peñaloza
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:
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.



Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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.
Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Tudor Girba
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."





Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Veronica Isabel Uquillas Gomez
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."






Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Veronica Isabel Uquillas Gomez
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.
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Veronica Isabel Uquillas Gomez
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.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse

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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Noury Bouraqadi-2
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>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Igor Stasenko
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.
>
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.

Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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>
>>
>>
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Stéphane Ducasse
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Ring - model infrastructure for Pharo

Marcus Denker-4
In reply to this post by Veronica Isabel Uquillas Gomez

On Dec 10, 2010, at 2:33 PM, 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). 

#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.

12