Smalltalk › Pharo › Pharo Smalltalk Developers

Ring - model infrastructure for Pharo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

Veronica Isabel Uquillas Gomez

Re: Ring - model infrastructure for Pharo

On 13 Dec 2010, at 12:40, Marcus Denker wrote:

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?

the format is different for RecentMessageList

'Class >> #selector'

'Class(removed) >> #selector'

Is this class being used? Or its method #removeAMethod: ? I just noticed that it is invoking #methodSymbol: from MethodReference, but that method does not exist...

Without this, in fact we don't need an iVar, and we should manage an unique format

Marcus

--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Marcus Denker-4

Re: Ring - model infrastructure for Pharo

In reply to this post by Marcus Denker-4

> the format is different for RecentMessageList
> 'Class >> #selector'
> 'Class(removed) >> #selector'
> Is this class being used? Or its method #removeAMethod: ?
> I just noticed
> that it is invoking #methodSymbol: from MethodReference, but that method
> does not exist...
> Without this, in fact we don't need an iVar, and we should manage an unique
> format

Hmm... that looks strange. In general, MethodReference should not seen as
something defining what a general model needs, as it is in itself very
strange and
ugly. We need to carefully check.

The use of RecentMessageList seems to be more that it needs a general way
to associate meta-data with a reference ("I deleted this").

We should check the new stuff regarding RecentMessages that Benjamin did. Lots
of the old things should be removed...

--
Marcus Denker -- [hidden email]
http://www.marcusdenker.de

Stéphane Ducasse

Re: Ring - model infrastructure for Pharo

In reply to this post by Marcus Denker-4

>>
>>
> #stringVersionDefault has just one sender (#markMatchingClasses in SelectorBrowser). Do we need that?

let's happily kill it.

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

Stéphane Ducasse

Re: Ring - model infrastructure for Pharo

In reply to this post by Marcus Denker-4

> Hmm... that looks strange. In general, MethodReference should not seen as
> something defining what a general model needs, as it is in itself very
> strange and
> ugly. We need to carefully check.
>
> The use of RecentMessageList seems to be more that it needs a general way
> to associate meta-data with a reference ("I deleted this").
>
> We should check the new stuff regarding RecentMessages that Benjamin did. Lots
> of the old things should be removed...

Igor Stasenko

Re: Ring - model infrastructure for Pharo

In reply to this post by Stéphane Ducasse

On 13 December 2010 20:44, Stéphane Ducasse <[hidden email]> wrote:
>>>
>>>
>> #stringVersionDefault has just one sender (#markMatchingClasses in SelectorBrowser). Do we need that?
>
> let's happily kill it.
>

yeah.
The less - the more. :)

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

--
Best regards,
Igor Stasenko AKA sig.

Peter van Rooijen

Re: Ring - model infrastructure for Pharo

In reply to this post by Veronica Isabel Uquillas Gomez

On Sat, 11 Dec 2010 19:34:12 +0100, Veronica Isabel Uquillas Gomez
<[hidden email]> 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

Stéphane Ducasse

Re: Ring - model infrastructure for Pharo

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