<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi all!<div><br></div><div>Hehe. "shadows + morphic" got me distracted. ^__^</div><div><br></div><div>Hmm... personally, I prefer "owner" over "anOwner" as block variable. That is, I don't care about shadowing the instVar name -- just locally focused readability. That is, I am a fan of accessors and thus rarely (? never ?) bitten by confusing instVar access and tempVar access. :-) For classes with longer methods and extensive instVar access (...Compiler?), shadowing can be an issue for code readability, though.</div><div><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> In a larger context, I would strongly opt for (finally) introducing a</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> mechanism for linter/compiler annotations in CodeHolders. Most modern</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> editors and IDEs have it, even Pharo; if Squeak does not want to get left</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> behind, we should support something like this, too. It could or should be</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> configurable, of course.</span><br></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">How come? While structured information is nice, I am opposed to introducing more things that are prone to errors. :-) What would you expect me to annotate in such a case? Marking intentional shadowing? I wouldn't want to. ;-) Tool-specific configuration/annotation -- yes, linter and compiler are tools -- should not interfere with an artifact's primary representation. For example, it's problematic that there is only a single #inspectorClass or #explorerContents per domain object. That does not scale; it can also obfuscate the object's interface. In a similar manner, if one would start to "enrich" source code with various annotations for all kinds of supported compilers/parsers/linters etc. ... nah. </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">There are already pragmas, which can be used to annotate methods. Sub-method annotation might be beneficial in not-too-frequent situations ... thus, maybe not worth the effort.</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 12.04.2021 21:32:34 schrieb Christoph Thiede <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Eliot,<br><br>I fear that changes like this will not be very durable unless tested in any<br>way. At the moment, you won't even notice a new shadow unless you have<br>opened a Transcript by accident when accepting a method. Should we maybe<br>show a message window for shadows instead when compiled interactively,<br>analogously to the warnings about superfluous temps?<br><br>(In a larger context, I would strongly opt for (finally) introducing a<br>mechanism for linter/compiler annotations in CodeHolders. Most modern<br>editors and IDEs have it, even Pharo; if Squeak does not want to get left<br>behind, we should support something like this, too. It could or should be<br>configurable, of course.)<br><br>LBNL, if I understand Chris correctly, "anOwner" might be a suboptimal name<br>for a variable that holds Morph instances, right? :)<br><br>Best,<br>Christoph<br><br><br><br>-----<br>Carpe Squeak!<br>--<br>Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br><br></div></blockquote></div>