<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 April 2018 at 02:49, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/6/18, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br>
</span><span class="">> Like this, but it would mean to replace all "ActiveWorld" with "ActiveWorld<br>
> value" calls:<br>
><br>
><br>
</span><span class="">> At the moment, we have #becomeActive:during: in HandMorph, MorphicEvent, and<br>
> PasteUpMorph for this.<br>
><br>
> Best,<br>
> Marcel<br>
<br>
</span>OK, thank you. I understand that you propose to make ActiveWorld<br>
(which is currently a global holding a PasteUpMorph) a subclass of<br>
DynamicVariable (which happens to be in the system since at least<br>
2007).<br>
<br>
--Hannes<br></blockquote><div><br></div><div>It also happens to be broken when combined with continuations.</div><div><br></div><div>Fortunately there's a package for that - the Control package lets you define _delimited_ dynamic variables, which work just fine with delimited continuations. (By the way, not an academic problem: delimited continuations are _everywhere_ in Squeak.</div><div><br></div><div>...and I see some kind soul was kind enough to update page 6481 with a chat between Tobias & I on the subject.</div><div><br></div><div>frank</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
<br>
> Am 06.04.2018 11:14:29 schrieb H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>>:<br>
> On 4/6/18, H. Hirzel wrote:<br>
>> Marcel,<br>
>><br>
>> is it possible to elaborate what is meant with 'Dynamic variable'?<br>
>><br>
>> A good place to do so here<br>
>><br>
>> <a href="http://wiki.squeak.org/squeak/6481" rel="noreferrer" target="_blank">http://wiki.squeak.org/squeak/<wbr>6481</a><br>
><br>
> I mean which type of DynamicVariable do you think of (as mentioned on<br>
> the draft notes on page 6481)<br>
><br>
>> :-)<br>
>><br>
>> --Hannes<br>
>><br>
>> On 4/6/18, Marcel Taeumel wrote:<br>
>>> -1 for Project class >> #currentWorld<br>
>>><br>
>>> The interface #currentWorld, #currentHand, and #currentEvent is already<br>
>>> there in Object to provide messaging for the dynamically-scoped<br>
>>> variables<br>
>>> ActiveWorld, ActiveHand, and ActiveEvent.<br>
>>><br>
>>> What about making ActiveWorld, ActiveHand, and ActiveEvent *actually* a<br>
>>> DynamicVariable? :-)<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>> Am 06.04.2018 06:44:49 schrieb tim Rowledge :<br>
>>><br>
>>> Now me personally, I don't like a proliferation of globals. Nor do I<br>
>>> like<br>
>>> a<br>
>>> long chain of structure/api asuming messages.<br>
>>><br>
>>> I posit that instead of 'World' we would be less confused and more<br>
>>> elegant<br>
>>> with'Project currentWorld', where Project is our friendly class and<br>
>>> #currentWorld is a method that determines the current Project instance<br>
>>> and<br>
>>> sends it a message to determine what the current world-equivalent is. We<br>
>>> may<br>
>>> have kinds of project where the world-equivalent depends upon some other<br>
>>> factor, for example.<br>
>>><br>
>>> My admittedly extreme view would be that we should never have chained<br>
>>> messages and instead do actual delegation from the beginning. Instead of<br>
>>> Project current world morphs allSatisfy:[:mrph| mrph<br>
>>> veryMorphSpecificThing<br>
>>> comparedTo: otherThing extremelyThingRelatedAttribute<br>
>>> internalStructureAssumingMessa<wbr>ge]<br>
>>> I'd really prefer<br>
>>> Project widgetsThatMatchOtherThingStat<wbr>us<br>
>>> And yes, even there we are making assumptions about the internals of<br>
>>> Project<br>
>>> stuff. And I understand that it would likely be near-impossible to go<br>
>>> that<br>
>>> far and stay sane. But who cares about being sane, eh? Have you seen my<br>
>>> water powered over-unity snake?<br>
>>><br>
>>> My point - and I do have one - is that every message send is a place to<br>
>>> make<br>
>>> a useful discrimination about what an object should do. Using messages<br>
>>> and<br>
>>> accompanying methods that are little more than C struct field name<br>
>>> analogues<br>
>>> is throwing away that valuable opportunity a.k.a simple accessors are<br>
>>> almost<br>
>>> always A Bad Thing. I mean, you have heard of encapsulation, right? and<br>
>>> abstraction?<br>
>>><br>
>>> I now return you to your regularly scheduled diet of whatever. On toast.<br>
>>><br>
>>> tim<br>
>>> --<br>
>>> tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
>>> Strange OpCodes: CRN: Compare to Random Number<br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>