[Pharo-dev] what is the new way to do Smalltalk at: #MyClass?

Camille Teruel camille.teruel at gmail.com
Mon Aug 26 10:20:47 EDT 2013


On 26 août 2013, at 15:04, Igor Stasenko wrote:

> 
> 
> 
> On 26 August 2013 14:34, Camille Teruel <camille.teruel at gmail.com> 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.

In the current system (in fact since Pharo 1.3 I think) we have that:

Object subclass: #A.
envA := SystemDictionary new.
envA at: #Smalltalk put: 33.
A environment: envA.
A compile: 'st ^ Smalltalk'.
A new st
-----> 33

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

Again, that doesn't change the semantic! 
The problems will only appear once several environment will be introduced.
Code in dev tools that try to fetch a global via ThisEnvironment (the one of tool package) instead of someClass environment (the one of a class the tool display, inspect, browse...).
The very same problems would happen with #asClass, except that this time, we'll have to revisit all the senders of #asClass and company.

> 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 just ensure to lock the system in its current state...

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


So browsing senders of #asClass, #asClassIfPresent:, #asClassIfAbsent: and #asClassIfAbsent:ifPresent: is much more easy than browsing reference to ThisEnvironment?
And you would most probably never have to visit the reference to ThisEnvironment...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130826/293a9703/attachment-0002.html>


More information about the Pharo-dev mailing list