<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 30.07.2019, at 18:53, Christoph Thiede <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
> <br>
> Hi Tobias,<br>
> <br>
> isn't `Smalltalk at: #some ifPresent: [] ifAbsent: []` more convenient (and<br>
> strengthens encapsulation)?<br>
<br>
Doesn't it rather strengthen a God class?<br></blockquote><div><br></div><div>There's nothing inherently wrong with "strengthening" an existing core responsibility in a way that makes it easier to use from the outside.</div><br class="gmail-Apple-interchange-newline"><div>Being wary of God classes is just a tool for assisting with what really matters -- identifying the proper delegation of responsibility.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I thought this would also be the reason for<br>
> SmalltalkImage>>#at:ifPresent: & Co. ...<br>
<br>
There had been different approaches to fan out responsibilities from the Smalltalk global to <br>
other objects, and different views to consolidate.<br>
<br>
Anyhow, given that there are environments now and Smalltalk globals is actually not a SystemDictionary anymore but an Environment,<br>
at lease the access to global names, variables and classes should rather go through globals :)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.  </div><div><br></div><div>+1 for trunk.<br></div><div><br></div><div> - Chris</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>