Smalltalk › Squeak › Squeak - Dev

The Inbox: System-ct.1073.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

commits-2

The Inbox: System-ct.1073.mcz

A new version of System was added to project The Inbox:
http://source.squeak.org/inbox/System-ct.1073.mcz

==================== Summary ====================

Name: System-ct.1073
Author: ct
Time: 30 July 2019, 5:18:34.214556 pm
UUID: 8e29c8e1-c869-c541-b274-e0beb170c532
Ancestors: System-kfr.1072

Add SmalltalkImage>>#at:ifPresent:ifAbsent:

A shorthand for SmalltalkImage globals access

=============== Diff against System-kfr.1072 ===============

Item was added:
+ ----- Method: SmalltalkImage>>at:ifPresent:ifAbsent: (in category 'accessing') -----
+ at: key ifPresent: aBlock ifAbsent: anotherBlock
+
+ ^globals at: key ifPresent: aBlock ifAbsent: anotherBlock!

Tobias Pape

Re: The Inbox: System-ct.1073.mcz

Hey Christoph

> On 30.07.2019, at 17:18, [hidden email] wrote:
>
> A new version of System was added to project The Inbox:
> http://source.squeak.org/inbox/System-ct.1073.mcz
>
> ==================== Summary ====================
>
> Name: System-ct.1073
> Author: ct
> Time: 30 July 2019, 5:18:34.214556 pm
> UUID: 8e29c8e1-c869-c541-b274-e0beb170c532
> Ancestors: System-kfr.1072
>
> Add SmalltalkImage>>#at:ifPresent:ifAbsent:
>
> A shorthand for SmalltalkImage globals access
>
> =============== Diff against System-kfr.1072 ===============
>
> Item was added:
> + ----- Method: SmalltalkImage>>at:ifPresent:ifAbsent: (in category 'accessing') -----
> + at: key ifPresent: aBlock ifAbsent: anotherBlock
> +
> + ^globals at: key ifPresent: aBlock ifAbsent: anotherBlock!
>
>

Why not use `Smalltalk globals at: #some ifPresent: [] ifAbsent: []`

Best regards
-Tobias

Christoph Thiede

Re: The Inbox: System-ct.1073.mcz

Hi Tobias,

isn't `Smalltalk at: #some ifPresent: [] ifAbsent: []` more convenient (and
strengthens encapsulation)? I thought this would also be the reason for
SmalltalkImage>>#at:ifPresent: & Co. ...

Best,
Christoph

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!

Tobias Pape

Re: The Inbox: System-ct.1073.mcz

> On 30.07.2019, at 18:53, Christoph Thiede <[hidden email]> wrote:
>
> Hi Tobias,
>
> isn't `Smalltalk at: #some ifPresent: [] ifAbsent: []` more convenient (and
> strengthens encapsulation)?

Doesn't it rather strengthen a God class?

> 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 :)

at least that's my view

Best regards
-Tobias

Chris Muller-3

Re: The Inbox: System-ct.1073.mcz

> On 30.07.2019, at 18:53, Christoph Thiede <[hidden email]> 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

Jakob Reschke

Re: The Inbox: System-ct.1073.mcz

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 <[hidden email]>:

> On 30.07.2019, at 18:53, Christoph Thiede <[hidden email]> 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