<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        -1 for Project class >> #currentWorld<div><br></div><div>The interface #currentWorld, #currentHand, and #currentEvent is already there in Object to provide messaging for the dynamically-scoped variables ActiveWorld, ActiveHand, and ActiveEvent.</div><div><br></div><div>What about making ActiveWorld, ActiveHand, and ActiveEvent *actually* a DynamicVariable? :-)</div><div><br></div><div>Best,</div><div>Marcel</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 06.04.2018 06:44:49 schrieb tim Rowledge <tim@rowledge.org>:</p><br>Now me personally, I don't like a proliferation of globals. Nor do I like a long chain of structure/api asuming messages.<br><br>I posit that instead of 'World' we would be less confused and more elegant with'Project currentWorld', where Project is our friendly class and #currentWorld is a method that determines the current Project instance and sends it a message to determine what the current  world-equivalent is.  We may have kinds of project where the world-equivalent depends upon some other factor, for example.<br><br>My admittedly extreme view would be that we should never have chained messages and instead do actual delegation from the beginning. Instead of <br>Project current world morphs allSatisfy:[:mrph| mrph veryMorphSpecificThing comparedTo: otherThing extremelyThingRelatedAttribute internalStructureAssumingMessage]<br>I'd really prefer<br>Project widgetsThatMatchOtherThingStatus<br>And yes, even there we are making assumptions about the internals of Project stuff. And I understand that it would likely be near-impossible to go that far and stay sane. But who cares about being sane, eh? Have you seen my water powered over-unity snake?<br><br>My point - and I do have one - is that every message send is a place to make a useful discrimination about what an object should do. Using messages and accompanying methods that are little more than C struct field name analogues is throwing away that valuable opportunity a.k.a simple accessors are almost always A Bad Thing. I mean, you have heard of encapsulation, right? and abstraction?<br><br>I now return you to your regularly scheduled diet of whatever. On toast.<br><br>tim<br>--<br>tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim<br>Strange OpCodes: CRN: Compare to Random Number<br><br><br><br>
                        </blockquote></div>