<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Tim.<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">*If* we had private methods one could mark foobleDong as private and thereby safely use it internally.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">As long as programmers cannot make their intent clear with a "private" category or "pvt"-prefix in selectors or just by intentionally (!) using instVars without accessors, having extra annotations for lookup visibility (e.g. public/private/protected) will not make things any better as they are now. We have idioms and patterns for this already.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Sure, programmers that keep on ignoring an interface's intent would be punished if such lookup visibility would be enforced. However, I don't think that's a good way to move forward with Squeak/Smalltalk. ;-) It would lock up the system in a way that might impair liveness and exploration.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Instead, tools can help programmers discover and correct their mistakes. Code critiques, linting tools, code browsers w/ embedded run-time information, ...</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 21.07.2020 19:08:55 schrieb tim Rowledge <tim@rowledge.org>:</p><div style="font-family:Arial,Helvetica,sans-serif"><br><br>> On 2020-07-21, at 1:36 AM, Marcel Taeumel <marcel.taeumel@hpi.de> wrote:<br>> <br>> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.<br><br>I've always been a bit ambivalent about the lazy initialisation stuff; not that it doesn't have uses. The problematic bit in my experience is tied to the lack of properly private messages and the disappointing propensity of people to treat Smalltalk as C code.<br><br>To explain: one decides to have lazy init for an instvar and so creates a methods named as the instvar that does the nil check and init dance. Great - now you can write<br>`self foobleDong`<br>and guarantee to get a useful answer. The problem now is that you have made your class into little more than a C struct. Any old Thomas, Richard or Harold can send #foobleDong and get at the internal state of your object. I don't like that.<br>*If* we had private methods one could mark foobleDong as private and thereby safely use it internally. <br><br>I see far too much 'Cmalltalk' where messages are being sent as if they were C struct accessor operators. I really hate seeing<br>`myThing foo fum bar baz bing: myThing foo fum bar baz bing + 1`<br><br><br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>"Bother!" said Pooh, as he stood up to his waist in a cow pat.<br><br><br><br></marcel.taeumel@hpi.de></div></blockquote></div>