[squeak-dev] The Inbox: System-ct.1073.mcz

Jakob Reschke forums.jakob at resfarm.de
Thu Aug 1 08:35:28 UTC 2019


Smalltalk globals at:... does not give you a lookup in the "dynamic
environment", it is as restricted as Smalltalk at:... in that regard. A
method is compiled in a certain environment. By default it is the "home"
environment of the containing class. That environment determines what
"Smalltalk" is bound to (if anything at all), and consequently what its
globals are.

Smalltalk at:.... is a dynamic lookup in the "lexical" environment (quotes
because it is determined by the System or the tools, not by text).
Environment current valueOf:... is a dynamic lookup in the dynamic
environment.
Just using a name is a compile-time lookup in the "lexical" environment,
except that the binding is used, not only the value. Thus, the referenced
class can later change its name and the CompiledMethod still works.

Good news: for most code, the dynamic environment is irrelevant, since
there was no such thing in Smalltalk in the beginning. It is relevant only
for code that must "think outside the box" and must deal with the presence
of other environments. At minimum, the coding tools and the code leading up
to compilation must do that because otherwise you cannot work on classes in
other environments. Such code must not use "Smalltalk" at all; it neither
matters whether "globals" is being used, nor which variant of
at:/ifPresent:/ifAbsent:.

Just ensure that Environment has the same lookup accessor if you add one to
SmalltalkImage.

Am Do., 1. Aug. 2019 um 05:09 Uhr schrieb Chris Muller <asqueaker at gmail.com
>:

>
>> > On 30.07.2019, at 18:53, Christoph Thiede <
>> christoph.thiede at student.hpi.uni-potsdam.de> wrote:
>> >
>> > Hi Tobias,
>> >
>> > isn't `Smalltalk at: #some ifPresent: [] ifAbsent: []` more convenient
>> (and
>> > strengthens encapsulation)?
>>
>> Doesn't it rather strengthen a God class?
>>
>
> There's nothing inherently wrong with "strengthening" an existing core
> responsibility in a way that makes it easier to use from the outside.
>
> Being wary of God classes is just a tool for assisting with what really
> matters -- identifying the proper delegation of responsibility.
>
>
>>
>> > I thought this would also be the reason for
>> > SmalltalkImage>>#at:ifPresent: & Co. ...
>>
>> There had been different approaches to fan out responsibilities from the
>> Smalltalk global to
>> other objects, and different views to consolidate.
>>
>> Anyhow, given that there are environments now and Smalltalk globals is
>> actually not a SystemDictionary anymore but an Environment,
>> at lease the access to global names, variables and classes should rather
>> go through globals :)
>>
>
> I suspect one reason no one uses Environments (plesae correct me if I'm
> wrong about that) is because it fundamentally only solves half the problem
> it sets out to solve.  There's still an unavoidable possibility that
> co-existence of a disparate packages will result in one of them to needing
> to be modified (i.e., a simple collision on an extension method would do
> the trick), which puts you right back at square 1, except with your system
> now complicated by a partitioned namespace.
>
> So, for most, "there are environments" is not really a true statement --
> there is still just original, classic Smalltalk-80; one global namespace.
> Simple, beautiful.  But that experimental Environments code is still in
> there, if one is inclined to play with it.
>
> In the meantime, SmalltalkImage already has #at:ifAbsent:,
> #at:ifAbsentPut:, #at:ifPresent:, and at:ifPresentAndInMemory:.  Given that
> no case was made against their presence, I should be fine to include this
> one too, which'll help Smalltalk be more to be consistent with Dictionary
> API.
>
> +1 for trunk.
>
>  - Chris
>
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190801/5b7ed1a2/attachment.html>


More information about the Squeak-dev mailing list