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

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