On 4/6/18, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> Like this, but it would mean to replace all "ActiveWorld" with "ActiveWorld
> value" calls:
>
>
> At the moment, we have #becomeActive:during: in HandMorph, MorphicEvent, and
> PasteUpMorph for this.
>
> Best,
> Marcel

OK, thank you. I understand that you propose to make ActiveWorld
(which is currently a global holding a PasteUpMorph) a subclass of
DynamicVariable (which happens to be in the system since at least
2007).

--Hannes



> Am 06.04.2018 11:14:29 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
> On 4/6/18, H. Hirzel wrote:
>> 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
>
> I mean which type of DynamicVariable do you think of (as mentioned on
> the draft notes on page 6481)
>
>> :-)
>>
>> --Hannes
>>
>> On 4/6/18, Marcel Taeumel 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 :
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>
>