On 6 April 2018 at 02:49, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> 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
>

It also happens to be broken when combined with continuations.

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.

...and I see some kind soul was kind enough to update page 6481 with a chat
between Tobias & I on the subject.

frank



>
> > 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
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180406/509aed3a/attachment.html>