Marcel,

is it possible to elaborate what is meant with 'Dynamic variable'?

A good place to do so here

http://wiki.squeak.org/squeak/6481

:-)

--Hannes

On 4/6/18, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> -1 for Project class >> #currentWorld
>
> The interface #currentWorld, #currentHand, and #currentEvent is already
> there in Object to provide messaging for the dynamically-scoped variables
> ActiveWorld, ActiveHand, and ActiveEvent.
>
> What about making ActiveWorld, ActiveHand, and ActiveEvent *actually* a
> DynamicVariable? :-)
>
> Best,
> Marcel
> Am 06.04.2018 06:44:49 schrieb tim Rowledge <tim at rowledge.org>:
>
> Now me personally, I don't like a proliferation of globals. Nor do I like a
> long chain of structure/api asuming messages.
>
> 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.
>
> My admittedly extreme view would be that we should never have chained
> messages and instead do actual delegation from the beginning. Instead of
> Project current world morphs allSatisfy:[:mrph| mrph veryMorphSpecificThing
> comparedTo: otherThing extremelyThingRelatedAttribute
> internalStructureAssumingMessage]
> I'd really prefer
> Project widgetsThatMatchOtherThingStatus
> 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?
>
> 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?
>
> I now return you to your regularly scheduled diet of whatever. On toast.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CRN: Compare to Random Number
>
>
>
>