<html><head></head><body> <div dir="auto">For that matter, I’ve been contemplating how useful it would be to have inline initializers for method variables, like:</div><div dir="auto"><br></div><div dir="auto"> | arg1<#fortyTwo> arg2<42> arg3 <[6*7]> |<caret></caret></div><div><br></div><div id="protonmail_signature_block" class="protonmail_signature_block"><div>—<br>Have a good one; keep it, light.<br>Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇<br><br>Sent from Callisto House mobile - Ganymede<br>:: decentralized mobile homeless solutions ::</div></div> <div class="signature_br" contenteditable="false"><br></div><div class="signature_br" contenteditable="false"><br></div> <div><br></div><div><br></div>On Tue, Mar 21, 2023 at 18:13, rabbit via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" class="">cuis-dev@lists.cuis.st</a>> wrote:<blockquote class="protonmail_quote" type="cite"> <div dir="auto">Would it be possible to install a block in the variable, on compilation, when undefined to auto-do during evaluation access to that variable…</div><div dir="auto"><br></div><div dir="auto"> [thisContext </div><div dir="auto"> setVariable: #varName </div><div dir="auto"> put: (Smalltalk at: #varName). </div><div dir="auto"> Smalltalk at: #varName]</div><div dir="auto"><br></div>…for purposes of intuition.<div dir="auto">🐰<br><div id="protonmail_signature_block" class="protonmail_signature_block"><div>—<br>Have a good one; keep it, light.<br>Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇<br><br>Sent from Callisto House mobile - Ganymede<br>:: decentralized mobile homeless solutions ::</div></div> <div class="signature_br" contenteditable="false"><br></div><div class="signature_br" contenteditable="false"><br></div> <div><br></div><div><br></div>On Tue, Mar 21, 2023 at 17:41, ken.dickey--- via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" class="">cuis-dev@lists.cuis.st</a>> wrote:<blockquote class="protonmail_quote" type="cite"> On 2023-03-21 12:57, Alexandre Rousseau via Cuis-dev wrote:<br><br>> My point was the system complained that "MyTheme beCurrent " , scripted<br>> after the loading of said packaged theme, was pointing to a non<br>> existent class ... i.e., the loading was not complete when the<br>> "beCurrent" message was sent. Which makes the loading of packages<br>> asynchronous, does it not?<br><br>Actually, not. It is a processing time problem.<br><br>The code is first compiled as _a block_ and when that happens<br>#ClassicTheme is undefined, so nil.<br><br>If you initially type<br> Feature require: #'Theme-Themes'.<br> ClassicTheme beCurrent.<br>into a workspace, you will see #ClassicTheme in RED because it is yet<br>undefined.<br><br>If you select both lines and DoIt, you will get the #ClassicTheme<br>undefined exception, but if you select the first line and DoIt, then you<br>will note #ClassicTheme has turned BLUE as it is now defined. You can<br>select the 2nd line and DoIt, AOK.<br><br>Since you are sending a block of text to be compiled at one time, you<br>have to deal with undefined values _at the time the text is compiled_.<br><br>The easy fix in this case is to compile-in the explicit code to do the<br>lookup:<br> Feature require: #'Theme-Themes'.<br> (Smalltalk at: #ClassicTheme) beCurrent.<br><br>Note that I do not find this very intuitive either.<br><br>HTH,<br>-KenD<br><br>--<br>Cuis-dev mailing list<br>Cuis-dev@lists.cuis.st<br>https://lists.cuis.st/mailman/listinfo/cuis-dev<br></blockquote></div></blockquote></body></html>