what is the new way to do Smalltalk at: #MyClass?

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

what is the new way to do Smalltalk at: #MyClass?

Stéphane Ducasse

Is it

asClass?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Fernando olivero-2
I prefer to evaluate

Smalltalk globals classNamed: #MyClass

Fernando

On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
<[hidden email]> wrote:
>
> Is it
>
> asClass?
>
> Stef
>

Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Camillo Bruni-3
We have now:

String >> #asClass
String >> #asClassIfAbsent:
String >> #asClassIfPresent:

On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:

> I prefer to evaluate
>
> Smalltalk globals classNamed: #MyClass
>
> Fernando
>
> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
> <[hidden email]> wrote:
>>
>> Is it
>>
>> asClass?
>>
>> Stef
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Stéphane Ducasse

On Aug 24, 2013, at 7:20 PM, Camillo Bruni <[hidden email]> wrote:

> We have now:
>
> String >> #asClass
> String >> #asClassIfAbsent:
> String >> #asClassIfPresent:

Ok I found them. I was working in an older image
What was strange is that he method finder did not find it when I did #Point . Point

>
> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>> I prefer to evaluate
>>
>> Smalltalk globals classNamed: #MyClass
>>
>> Fernando
>>
>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>
>>> Is it
>>>
>>> asClass?
>>>
>>> Stef
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Camillo Bruni-3
On 2013-08-24, at 20:52, Stéphane Ducasse <[hidden email]> wrote:
> On Aug 24, 2013, at 7:20 PM, Camillo Bruni <[hidden email]> wrote:
>> We have now:
>>
>> String >> #asClass
>> String >> #asClassIfAbsent:
>> String >> #asClassIfPresent:
>
> Ok I found them. I was working in an older image
> What was strange is that he method finder did not find it when I did #Point . Point

the method finder is not good for much since someone has to manually specify which methods to take into account and add them to a list of selectors.


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Stéphane Ducasse

On Aug 24, 2013, at 8:54 PM, Camillo Bruni <[hidden email]> wrote:

> On 2013-08-24, at 20:52, Stéphane Ducasse <[hidden email]> wrote:
>> On Aug 24, 2013, at 7:20 PM, Camillo Bruni <[hidden email]> wrote:
>>> We have now:
>>>
>>> String >> #asClass
>>> String >> #asClassIfAbsent:
>>> String >> #asClassIfPresent:
>>
>> Ok I found them. I was working in an older image
>> What was strange is that he method finder did not find it when I did #Point . Point
>
> the method finder is not good for much since someone has to manually specify which methods to take into account and add them to a list of selectors.

Yes I was thinking on how to improve that. It passes by method metadata. I was writing a topics in my 50 topics for Pharo database I should issue soon.
The handling of metadata is not simple.



Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

camille teruel
In reply to this post by Camillo Bruni-3

On 24 août 2013, at 19:20, Camillo Bruni wrote:

> We have now:
>
> String >> #asClass
> String >> #asClassIfAbsent:
> String >> #asClassIfPresent:

I don't understand why we need this new way.
Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
And #asClass has no sender.
If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.


>
> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>> I prefer to evaluate
>>
>> Smalltalk globals classNamed: #MyClass
>>
>> Fernando
>>
>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>
>>> Is it
>>>
>>> asClass?
>>>
>>> Stef
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

EstebanLM

On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:

>
> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>
>> We have now:
>>
>> String >> #asClass
>> String >> #asClassIfAbsent:
>> String >> #asClassIfPresent:
>
> I don't understand why we need this new way.
> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?

exactly

> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
> And #asClass has no sender.
> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.

this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
At least, that was my understanding when the issue arise at the beginning.

Esteban

>
>
>>
>> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>>> I prefer to evaluate
>>>
>>> Smalltalk globals classNamed: #MyClass
>>>
>>> Fernando
>>>
>>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>>> <[hidden email]> wrote:
>>>>
>>>> Is it
>>>>
>>>> asClass?
>>>>
>>>> Stef
>>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Damien Cassou
On Mon, Aug 26, 2013 at 10:56 AM, Esteban Lorenzano <[hidden email]> wrote:
> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
> At least, that was my understanding when the issue arise at the beginning.


thinking about it, wouldn't "self asClass: #MyClass" be easier to
adapt for environments/packages than "#MyClass asClass" ?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

EstebanLM
I do not see why

On Aug 26, 2013, at 11:14 AM, Damien Cassou <[hidden email]> wrote:

> On Mon, Aug 26, 2013 at 10:56 AM, Esteban Lorenzano <[hidden email]> wrote:
>> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
>> At least, that was my understanding when the issue arise at the beginning.
>
>
> thinking about it, wouldn't "self asClass: #MyClass" be easier to
> adapt for environments/packages than "#MyClass asClass" ?
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm."
> Winston Churchill
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Damien Cassou
On Mon, Aug 26, 2013 at 11:26 AM, Esteban Lorenzano <[hidden email]> wrote:
> I do not see why


because it means we can override #asClass: in each class and do
whatever we want.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

NorbertHartl
In reply to this post by EstebanLM

Am 26.08.2013 um 10:56 schrieb Esteban Lorenzano <[hidden email]>:

>
> On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:
>
>>
>> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>>
>>> We have now:
>>>
>>> String >> #asClass
>>> String >> #asClassIfAbsent:
>>> String >> #asClassIfPresent:
>>
>> I don't understand why we need this new way.
>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
>
> exactly
>
>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
>> And #asClass has no sender.
>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.
>
> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
> At least, that was my understanding when the issue arise at the beginning.
>
I just find it strange that an as* selector might _not_ return anything needing a #asClassIfAbsent: selector. While I'm understanding the intention it does not fit in my had. To me it worsens the understanding of as* conversion selectors.

Norbert

>
>>
>>
>>>
>>> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>>>> I prefer to evaluate
>>>>
>>>> Smalltalk globals classNamed: #MyClass
>>>>
>>>> Fernando
>>>>
>>>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Is it
>>>>>
>>>>> asClass?
>>>>>
>>>>> Stef
>>>>>
>>>>
>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Camillo Bruni-3

On 2013-08-26, at 11:46, Norbert Hartl <[hidden email]> wrote:

>
> Am 26.08.2013 um 10:56 schrieb Esteban Lorenzano <[hidden email]>:
>
>>
>> On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:
>>
>>>
>>> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>>>
>>>> We have now:
>>>>
>>>> String >> #asClass
>>>> String >> #asClassIfAbsent:
>>>> String >> #asClassIfPresent:
>>>
>>> I don't understand why we need this new way.
>>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
>>
>> exactly
>>
>>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
>>> And #asClass has no sender.
>>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.
>>
>> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
>> At least, that was my understanding when the issue arise at the beginning.
>>
> I just find it strange that an as* selector might _not_ return anything needing a #asClassIfAbsent: selector. While I'm understanding the intention it does not fit in my had. To me it worsens the understanding of as* conversion selectors.

It works the same way as the dictionary protocol with #at:
`#adsfasdf asClass` will signal an error, hence for compatibility you have the *IfAbsent: protocols. Otherwise you simply cannot replace all the users of `Smalltalk at:` and `Smalltalk globals at:` which is the long term goal.


signature.asc (457 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Stéphane Ducasse
>
>
> It works the same way as the dictionary protocol with #at:
> `#adsfasdf asClass` will signal an error, hence for compatibility you have the *IfAbsent: protocols. Otherwise you simply cannot replace all the users of `Smalltalk at:` and `Smalltalk globals at:` which is the long term goal.

Cool mid term goal.
I should not start with it but I really would like :)


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

camille teruel
In reply to this post by EstebanLM

On 26 août 2013, at 10:56, Esteban Lorenzano wrote:

>
> On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:
>
>>
>> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>>
>>> We have now:
>>>
>>> String >> #asClass
>>> String >> #asClassIfAbsent:
>>> String >> #asClassIfPresent:
>>
>> I don't understand why we need this new way.
>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
>
> exactly
>
>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
>> And #asClass has no sender.
>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.
>
> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
> At least, that was my understanding when the issue arise at the beginning.

It's not a better abstraction, it's a worse one.
Sending #asClass to a symbol will ever execute the same method that anyway as to rely on a global: Smalltalk.
And this global is solved in only one environment: the one of the class Symbol where #asClass and co. are implemented.
So if you want separated environments you know what kind of thing you'll end up writing?

'#Foo asClassInEnvitonment: self class environment'

or implementing:

Symbol>>#asClass
        ^ self asClassInEnvironment: thisContext sender receiver class environment

However, as soon as the compiler use the environment of the compiled method's class to solves the globals it contains, Smalltalk can refer to anything.
So the only problem with: 'Smalltalk globals at:'  is that you send a message #globals to the global Smalltalk to fetch the environment while we could just have a global ThisEnvironment pointing to itself.

Writting 'ThisEnvironment at: #Foo' is much more natural.

If we want separated environments, each environment just have to define a binding ThisEnvironment pointing to itself and everything works well.
What I don't like with #asClass and co. is the style: you talk to a symbol instead of an environment.
It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter to: receiver', etc...

In Smalltalk we already have self to refer to the current receiver and thisContext to refer to the current stack frame. If we want different environments, is it that weird to have a ThisEnvironment to refer to the current environment?

>
> Esteban
>
>>
>>
>>>
>>> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>>>> I prefer to evaluate
>>>>
>>>> Smalltalk globals classNamed: #MyClass
>>>>
>>>> Fernando
>>>>
>>>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Is it
>>>>>
>>>>> asClass?
>>>>>
>>>>> Stef
>>>>>
>>>>
>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Igor Stasenko
the intent was to replace
Smalltalk at:
Smalltalk globals at:

idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future problems with introduction of environments.
And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay).
Whatever we will use for binding symbols in local environment, this is orthogonal.

Now you proposing introduce
ThisEnvironment at:

which getting back where we started from.
Unless , in your vision ThisEnvironment handled by compiler (like thisContext)..
so there will be no new global, but ThisEnvironment bound at compile time.

anyways, it will be semantically different from what we have now,
it will lookup for symbol in local environment, instead of global one.
And this is not going to happen (you cannot replace
Smalltalk globals at: with ThisEnvironment at: without overlooking all the places where it used)...
while replacing it with #asClass is fine (because semantics stays same).

Also, #asClass means 'give me the class or throw error', while
Smalltalk globals at: , obviously don't do that and gives you any object bound to given symbol, if it there.




On 26 August 2013 12:31, Camille Teruel <[hidden email]> wrote:

On 26 août 2013, at 10:56, Esteban Lorenzano wrote:

>
> On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:
>
>>
>> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>>
>>> We have now:
>>>
>>> String >> #asClass
>>> String >> #asClassIfAbsent:
>>> String >> #asClassIfPresent:
>>
>> I don't understand why we need this new way.
>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
>
> exactly
>
>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
>> And #asClass has no sender.
>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.
>
> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
> At least, that was my understanding when the issue arise at the beginning.

It's not a better abstraction, it's a worse one.
Sending #asClass to a symbol will ever execute the same method that anyway as to rely on a global: Smalltalk.
And this global is solved in only one environment: the one of the class Symbol where #asClass and co. are implemented.
So if you want separated environments you know what kind of thing you'll end up writing?

'#Foo asClassInEnvitonment: self class environment'

or implementing:

Symbol>>#asClass
        ^ self asClassInEnvironment: thisContext sender receiver class environment

However, as soon as the compiler use the environment of the compiled method's class to solves the globals it contains, Smalltalk can refer to anything.
So the only problem with: 'Smalltalk globals at:'  is that you send a message #globals to the global Smalltalk to fetch the environment while we could just have a global ThisEnvironment pointing to itself.

Writting 'ThisEnvironment at: #Foo' is much more natural.

If we want separated environments, each environment just have to define a binding ThisEnvironment pointing to itself and everything works well.
What I don't like with #asClass and co. is the style: you talk to a symbol instead of an environment.
It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter to: receiver', etc...

In Smalltalk we already have self to refer to the current receiver and thisContext to refer to the current stack frame. If we want different environments, is it that weird to have a ThisEnvironment to refer to the current environment?

>
> Esteban
>
>>
>>
>>>
>>> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>>>> I prefer to evaluate
>>>>
>>>> Smalltalk globals classNamed: #MyClass
>>>>
>>>> Fernando
>>>>
>>>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Is it
>>>>>
>>>>> asClass?
>>>>>
>>>>> Stef
>>>>>
>>>>
>>>
>>>
>>
>>
>
>





--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

camille teruel

On 26 août 2013, at 13:31, Igor Stasenko wrote:

the intent was to replace
Smalltalk at:
Smalltalk globals at:

idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future problems with introduction of environments.

We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it.

Also the references to Smalltalk globals that where really wrong are already gone and were in compiler.

And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay)

Globals are global to their environment. We could also call them environment variable. 

Whatever we will use for binding symbols in local environment, this is orthogonal.
Now you proposing introduce
ThisEnvironment at:

which getting back where we started from. 

No because ThisEnvironment would be an instance of Environment (basically a refactored SystemDictionary) not of SmalltalkImage. 
So who should be in charge of knowing how to handle accessible variable?
An instance of Environment with a nice api or an instance of Symbol by herself?

Unless , in your vision ThisEnvironment handled by compiler (like thisContext)..
so there will be no new global, but ThisEnvironment bound at compile time.

anyways, it will be semantically different from what we have now,
it will lookup for symbol in local environment, instead of global one.

ThisEnvironment would not be different than any other global.
There is no semantic change, no magic, nothing.
That's what the compiler already does.
The compiler use the environment of the class of the method being compiled to resolve globals. 
It happens that all classes currently share the same environment, that's something else.


And this is not going to happen (you cannot replace
Smalltalk globals at: with ThisEnvironment at: without overlooking all the places where it used)...
while replacing it with #asClass is fine (because semantics stays same).

Also, #asClass means 'give me the class or throw error', while
Smalltalk globals at: , obviously don't do that and gives you any object bound to given symbol, if it there.

Any control?
at:ifAbsent:
at:ifPresent:
at:ifAbsent:ifPresent:
are already there and if you want to ensure the global is a class you could have: classNamed:ifAbsent:ifPresent:





On 26 August 2013 12:31, Camille Teruel <[hidden email]> wrote:

On 26 août 2013, at 10:56, Esteban Lorenzano wrote:

>
> On Aug 25, 2013, at 9:40 AM, Camille Teruel <[hidden email]> wrote:
>
>>
>> On 24 août 2013, at 19:20, Camillo Bruni wrote:
>>
>>> We have now:
>>>
>>> String >> #asClass
>>> String >> #asClassIfAbsent:
>>> String >> #asClassIfPresent:
>>
>> I don't understand why we need this new way.
>> Is it just to avoid calling 'Smalltalk globals at: #MyClass'?
>
> exactly
>
>> Because these names are confusing, and the 'as' prefix suggests a conversion while it's an access (with indirection but still a mere access).
>> And #asClass has no sender.
>> If you think 'Smalltalk globals at: #MyClass' is really too long to type, lets just create a new global ThisEnvironment := Smalltalk globals.
>
> this was already discussed. With #asClass and relatives what you have is a better abstraction jut because you are decoupled of "Smalltalk globals", it is not a big win now, but it open doors to better designs with environments, etc.
> At least, that was my understanding when the issue arise at the beginning.

It's not a better abstraction, it's a worse one.
Sending #asClass to a symbol will ever execute the same method that anyway as to rely on a global: Smalltalk.
And this global is solved in only one environment: the one of the class Symbol where #asClass and co. are implemented.
So if you want separated environments you know what kind of thing you'll end up writing?

'#Foo asClassInEnvitonment: self class environment'

or implementing:

Symbol>>#asClass
        ^ self asClassInEnvironment: thisContext sender receiver class environment

However, as soon as the compiler use the environment of the compiled method's class to solves the globals it contains, Smalltalk can refer to anything.
So the only problem with: 'Smalltalk globals at:'  is that you send a message #globals to the global Smalltalk to fetch the environment while we could just have a global ThisEnvironment pointing to itself.

Writting 'ThisEnvironment at: #Foo' is much more natural.

If we want separated environments, each environment just have to define a binding ThisEnvironment pointing to itself and everything works well.
What I don't like with #asClass and co. is the style: you talk to a symbol instead of an environment.
It's like saying: '#key valueIn: aDict' instead of: 'aDict at: #key', 'letter beSentBy: postman to: receiver' instead of: 'postman send: letter to: receiver', etc...

In Smalltalk we already have self to refer to the current receiver and thisContext to refer to the current stack frame. If we want different environments, is it that weird to have a ThisEnvironment to refer to the current environment?

>
> Esteban
>
>>
>>
>>>
>>> On 2013-08-24, at 17:55, Fernando Olivero <[hidden email]> wrote:
>>>> I prefer to evaluate
>>>>
>>>> Smalltalk globals classNamed: #MyClass
>>>>
>>>> Fernando
>>>>
>>>> On Sat, Aug 24, 2013 at 11:57 AM, Stéphane Ducasse
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Is it
>>>>>
>>>>> asClass?
>>>>>
>>>>> Stef
>>>>>
>>>>
>>>
>>>
>>
>>
>
>





--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Igor Stasenko



On 26 August 2013 14:34, Camille Teruel <[hidden email]> wrote:

On 26 août 2013, at 13:31, Igor Stasenko wrote:

the intent was to replace
Smalltalk at:
Smalltalk globals at:

idioms with shorter one, and get rid of referencing Smalltalk global.
The are not for solving future problems with introduction of environments.

We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it.

Also the references to Smalltalk globals that where really wrong are already gone and were in compiler.

And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay)

Globals are global to their environment. We could also call them environment variable. 

Nope. In current system it is something else. It is a global variable not local to any environment.
And you will certainly have problems with old (and not so) code, if you swap the meaning (and underlying semantic)
of globals to anything else you may want.
This is what i trying to point out. In this case, #asClass is good, because it makes sure that old semantics will be preserved,
no matter what changes we may do.
It also will allow us to revisit all senders of #asClass and easily change them to something else when we will be ready for that..
and btw it will be much easier comparing to visiting all uses of Smalltalk or all uses of ThisEnvironment.


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

philippeback
... and Smalltalk should be renamed into Pharo anyway.

:-p

Phil



On Monday, August 26, 2013, Igor Stasenko <[hidden email]> wrote:
>
>
>
> On 26 August 2013 14:34, Camille Teruel <[hidden email]> wrote:
>>
>> On 26 août 2013, at 13:31, Igor Stasenko wrote:
>>
>> the intent was to replace
>> Smalltalk at:
>> Smalltalk globals at:
>>
>> idioms with shorter one, and get rid of referencing Smalltalk global.
>>
>> The are not for solving future problems with introduction of environments.
>>
>> We want to get rid of Smalltalk globals because it currently resolve to an instance of SmalltalkImage, a class that does way too much things, including holding the currently unique environment, while a global could directly refer to it.
>> Also the references to Smalltalk globals that where really wrong are already gone and were in compiler.
>>
>> And even if you introduce them, i still think you need a way to refer to globals (they are likely to stay)
>>
>> Globals are global to their environment. We could also call them environment variable. 
>
> Nope. In current system it is something else. It is a global variable not local to any environment.
> And you will certainly have problems with old (and not so) code, if you swap the meaning (and underlying semantic)
> of globals to anything else you may want.
> This is what i trying to point out. In this case, #asClass is good, because it makes sure that old semantics will be preserved,
> no matter what changes we may do.
> It also will allow us to revisit all senders of #asClass and easily change them to something else when we will be ready for that..
> and btw it will be much easier comparing to visiting all uses of Smalltalk or all uses of ThisEnvironment.
>
>
>

--
---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
 


Reply | Threaded
Open this post in threaded view
|

Re: what is the new way to do Smalltalk at: #MyClass?

Stéphane Ducasse

On Aug 26, 2013, at 3:54 PM, [hidden email] wrote:

> ... and Smalltalk should be renamed into Pharo anyway.
>
> :-p

:)

Camillo already wants systems.

Stef

12