Smalltalk › Squeak › Squeak - Dev

The Trunk: Morphic-cmm.1408.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

marcel.taeumel

Re: The Trunk: Morphic-cmm.1408.mcz

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

Am 06.04.2018 11:14:29 schrieb H. Hirzel <[hidden email]>:
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; [hidden email]; http://www.rowledge.org/tim
>> Strange OpCodes: CRN: Compare to Random Number
>>
>>
>>
>>
>

Hannes Hirzel

Re: The Trunk: Morphic-cmm.1408.mcz

On 4/6/18, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
> 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; [hidden email]; http://www.rowledge.org/tim
>>> Strange OpCodes: CRN: Compare to Random Number
>>>
>>>
>>>
>>>
>>
>
>

David T. Lewis

Re: Reducing ActiveWorld dependencies (was: The Trunk: Morphic-cmm.1408.mcz)

In reply to this post by marcel.taeumel

Hi Marcel,

Thanks for this list, it will be very helpful.

On Fri, Apr 06, 2018 at 10:20:27AM +0200, Marcel Taeumel wrote:

> Hi Dave,
>
> you are right. I double-checked the remaining "sends" of World. Those are only in DiskProxy, HandMorph, and MorphicProject. Seems to be load/unload code only.
>
> Much code uses ActiveWorld to trigger a UI cycle, which can be another issue to solve in the future. So, we see "ActiveWorld doOneCycleNow". It should be "Project current world doOneCycleNow" because it is Project-local. See MorphicProject >> #spawnNewProcess. Even if you think in terms of worlds-in-worlds.
>
> There are cases where "ActiveWorld" has the same problem as "World" such as in "ActiveWorld center". So "Project current world center" or even "self currentWorld" would be the fix -- even for class-side methods.
>
> For checks (in Morphs) like "self isInWorld ifTrue: [self world] ifFalse: [ActiveWorld]", ActiveWorld could also be "self currentWorld". Note that it does not make sense to override #currentWorld for Morph because the dynamic world (-in-world) scope is different from where the morph is actually contained.
>

That gives me an idea.

It seems that, by design, a Morph is not required to know its world.
But we have a number of places where senders are doing world ifNil
checks, and if all of those checks are doing basically the same thing
"if I do not know the world, then use Project current world as default")
then we could move the responsibility to Morph and get rid of the
conditional checks elsewhere.

So, instead of this:

Morph>>world
^owner isNil ifTrue: [nil] ifFalse: [owner world]

It could be this instead:

Morph>>world
owner ifNotNil: [ ^owner world ].
^Project current world

> Menu or halo invocation like "aMenu popUpEvent: ActiveEvent in: ActiveWorld" should be changed to use "self currentEvent" and "self currentWorld".
>
> "ActiveWorld restoreMorphicDisplay" should be rewritten to use the Project API: "Project current invalidate" or "Project current invalidate; restore" or "Project current displaySizeChanged".
>
> Best,
> Marcel
>
>
>
>
>
> Am 06.04.2018 05:12:48 schrieb David T. Lewis <[hidden email]>:
> On Thu, Apr 05, 2018 at 10:59:07AM +0200, Marcel Taeumel wrote:
> > Well, "ActiveWorld" is a dynamic variable that provides dynamic scope. Just like "ActiveEvent" and "ActiveHand". Useful and powerful in some cases. To be applied with caution. Yet, we have no alternative at the moment. Personally, I think we do not need any.
> >
> > "World" is a global variable that we do not need anymore since the addition of "Project" and the projects concept some time ago.
> >
> > Then, each visible morph has its own reference to a world. Usually, code should refer to this world when passing an instance as message argument.
> >
> > ---
> >
> > Currently, we have 6 senders of "World" left. We should make it 0.
>
> There should 0 senders of "World" already. The results of #browseAllCallsOn:
> are misleading, is that what you are looking at?
>
> I am seeing this:
>
> (CompiledMethod allInstances select: [ :e |
> (e literals select: [ :lit | (lit isKindOf: Global)
> and: [lit key == #World]]) isEmpty not]) size ==> 0
>
>
> > We also have 219 senders of "ActiveWorld" left. We should reduce that number to 10 or so in the core Morphic framework. Most of the other cases do not require ActiveWorld.
> >
>
> Yes!
>
> (CompiledMethod allInstances select: [ :e |
> (e literals select: [ :lit | (lit isKindOf: Global)
> and: [lit key == #ActiveWorld]]) isEmpty not]) size ==> 219
>
>
> I think that should be the next thing to go after. But I am not clear on
> the meanings. Before actually changing anything, I would want to try to
> get a clear understanding of the intended meaning of "ActiveWorld" and how
> it differs from "World". In particular I would want to be able to explain
> the cases where ActiveWorld is something other than Project current world.
>
> I suspect (but I am not sure) that these cases will be related to world-in-world
> handling, and that most other references to ActiveWorld are not really necessary
> as you are suggesting.
>
> Maybe Bob Arning can give us some guidance here if it is not clear.
>
> Dave
>
>

marcel.taeumel

Re: Reducing ActiveWorld dependencies (was: The Trunk: Morphic-cmm.1408.mcz)

Well, sometimes "isInWorld" would be needed instead of "self world isNil". So, it is a little bit more tricky... If nobody would ever check"self world isNil" but only use "self isInWorld" then: yes. I am afraid that this is not the case...

Best,

Marcel

Am 06.04.2018 15:03:22 schrieb David T. Lewis <[hidden email]>:
Hi Marcel,

Thanks for this list, it will be very helpful.

On Fri, Apr 06, 2018 at 10:20:27AM +0200, Marcel Taeumel wrote:
> Hi Dave,
>
> you are right. I double-checked the remaining "sends" of World. Those are only in DiskProxy, HandMorph, and MorphicProject. Seems to be load/unload code only.
>
> Much code uses ActiveWorld to trigger a UI cycle, which can be another issue to solve in the future. So, we see "ActiveWorld doOneCycleNow". It should be "Project current world doOneCycleNow" because it is Project-local. See MorphicProject >> #spawnNewProcess. Even if you think in terms of worlds-in-worlds.
>
> There are cases where "ActiveWorld" has the same problem as "World" such as in "ActiveWorld center". So "Project current world center" or even "self currentWorld" would be the fix -- even for class-side methods.
>
> For checks (in Morphs) like "self isInWorld ifTrue: [self world] ifFalse: [ActiveWorld]", ActiveWorld could also be "self currentWorld". Note that it does not make sense to override #currentWorld for Morph because the dynamic world (-in-world) scope is different from where the morph is actually contained.
>

That gives me an idea.

It seems that, by design, a Morph is not required to know its world.
But we have a number of places where senders are doing world ifNil
checks, and if all of those checks are doing basically the same thing
"if I do not know the world, then use Project current world as default")
then we could move the responsibility to Morph and get rid of the
conditional checks elsewhere.

So, instead of this:

Morph>>world
^owner isNil ifTrue: [nil] ifFalse: [owner world]

It could be this instead:

Morph>>world
owner ifNotNil: [ ^owner world ].
^Project current world

> Menu or halo invocation like "aMenu popUpEvent: ActiveEvent in: ActiveWorld" should be changed to use "self currentEvent" and "self currentWorld".
>
> "ActiveWorld restoreMorphicDisplay" should be rewritten to use the Project API: "Project current invalidate" or "Project current invalidate; restore" or "Project current displaySizeChanged".
>
> Best,
> Marcel
>
>
>
>
>
> Am 06.04.2018 05:12:48 schrieb David T. Lewis :
> On Thu, Apr 05, 2018 at 10:59:07AM +0200, Marcel Taeumel wrote:
> > Well, "ActiveWorld" is a dynamic variable that provides dynamic scope. Just like "ActiveEvent" and "ActiveHand". Useful and powerful in some cases. To be applied with caution. Yet, we have no alternative at the moment. Personally, I think we do not need any.
> >
> > "World" is a global variable that we do not need anymore since the addition of "Project" and the projects concept some time ago.
> >
> > Then, each visible morph has its own reference to a world. Usually, code should refer to this world when passing an instance as message argument.
> >
> > ---
> >
> > Currently, we have 6 senders of "World" left. We should make it 0.
>
> There should 0 senders of "World" already. The results of #browseAllCallsOn:
> are misleading, is that what you are looking at?
>
> I am seeing this:
>
> (CompiledMethod allInstances select: [ :e |
> (e literals select: [ :lit | (lit isKindOf: Global)
> and: [lit key == #World]]) isEmpty not]) size ==> 0
>
>
> > We also have 219 senders of "ActiveWorld" left. We should reduce that number to 10 or so in the core Morphic framework. Most of the other cases do not require ActiveWorld.
> >
>
> Yes!
>
> (CompiledMethod allInstances select: [ :e |
> (e literals select: [ :lit | (lit isKindOf: Global)
> and: [lit key == #ActiveWorld]]) isEmpty not]) size ==> 219
>
>
> I think that should be the next thing to go after. But I am not clear on
> the meanings. Before actually changing anything, I would want to try to
> get a clear understanding of the intended meaning of "ActiveWorld" and how
> it differs from "World". In particular I would want to be able to explain
> the cases where ActiveWorld is something other than Project current world.
>
> I suspect (but I am not sure) that these cases will be related to world-in-world
> handling, and that most other references to ActiveWorld are not really necessary
> as you are suggesting.
>
> Maybe Bob Arning can give us some guidance here if it is not clear.
>
> Dave
>
>

>

Bob Arning-2

Re: Reducing ActiveWorld dependencies

In reply to this post by David T. Lewis

There are places that expect a morph to answer nil if it is not currently in a world.

On 4/6/18 9:03 AM, David T. Lewis wrote:

Hi Marcel,

Thanks for this list, it will be very helpful.

On Fri, Apr 06, 2018 at 10:20:27AM +0200, Marcel Taeumel wrote:

Hi Dave,

you are right. I double-checked the remaining "sends" of World. Those are only in DiskProxy, HandMorph, and MorphicProject. Seems to be load/unload code only.

Much code uses ActiveWorld to trigger a UI cycle, which can be another issue to solve in the future. So, we see "ActiveWorld doOneCycleNow". It should be "Project current world doOneCycleNow" because it is Project-local. See MorphicProject >> #spawnNewProcess. Even if you think in terms of worlds-in-worlds.

There are cases where "ActiveWorld" has the same problem as "World" such as in "ActiveWorld center". So "Project current world center" or even "self currentWorld" would be the fix -- even for class-side methods.

For checks (in Morphs) like "self isInWorld ifTrue: [self world] ifFalse: [ActiveWorld]", ActiveWorld could also be "self currentWorld". Note that it does not make sense to override #currentWorld for Morph because the dynamic world (-in-world) scope is different from where the morph is actually contained.

That gives me an idea.

It seems that, by design, a Morph is not required to know its world.
But we have a number of places where senders are doing world ifNil
checks, and if all of those checks are doing basically the same thing 
"if I do not know the world, then use Project current world as default")
then we could move the responsibility to Morph and get rid of the
conditional checks elsewhere.

So, instead of this:

Morph>>world
	^owner isNil ifTrue: [nil] ifFalse: [owner world]

It could be this instead:

Morph>>world
	owner ifNotNil: [ ^owner world ].
	^Project current world

Menu or halo invocation like "aMenu popUpEvent: ActiveEvent in: ActiveWorld" should be changed to use "self currentEvent" and "self currentWorld".

"ActiveWorld restoreMorphicDisplay" should be rewritten to use the Project API: "Project current invalidate" or "Project current invalidate; restore" or "Project current displaySizeChanged".

Best,
Marcel





Am 06.04.2018 05:12:48 schrieb David T. Lewis [hidden email]:
On Thu, Apr 05, 2018 at 10:59:07AM +0200, Marcel Taeumel wrote:

Well, "ActiveWorld" is a dynamic variable that provides dynamic scope. Just like "ActiveEvent" and "ActiveHand". Useful and powerful in some cases. To be applied with caution. Yet, we have no alternative at the moment. Personally, I think we do not need any.

"World" is a global variable that we do not need anymore since the addition of "Project" and the projects concept some time ago.

Then, each visible morph has its own reference to a world. Usually, code should refer to this world when passing an instance as message argument.

---

Currently, we have 6 senders of "World" left. We should make it 0.

There should 0 senders of "World" already. The results of #browseAllCallsOn:
are misleading, is that what you are looking at?

I am seeing this:

(CompiledMethod allInstances select: [ :e |
(e literals select: [ :lit | (lit isKindOf: Global)
and: [lit key == #World]]) isEmpty not]) size ==> 0

We also have 219 senders of "ActiveWorld" left. We should reduce that number to 10 or so in the core Morphic framework. Most of the other cases do not require ActiveWorld.

Yes!

(CompiledMethod allInstances select: [ :e |
(e literals select: [ :lit | (lit isKindOf: Global)
and: [lit key == #ActiveWorld]]) isEmpty not]) size ==> 219


I think that should be the next thing to go after. But I am not clear on
the meanings. Before actually changing anything, I would want to try to
get a clear understanding of the intended meaning of "ActiveWorld" and how
it differs from "World". In particular I would want to be able to explain
the cases where ActiveWorld is something other than Project current world.

I suspect (but I am not sure) that these cases will be related to world-in-world
handling, and that most other references to ActiveWorld are not really necessary
as you are suggesting.

Maybe Bob Arning can give us some guidance here if it is not clear.

Dave

David T. Lewis

Re: Reducing ActiveWorld dependencies

On Fri, Apr 06, 2018 at 09:57:14AM -0400, Bob Arning wrote:
> There are places that expect a morph to answer nil if it is not
> currently in a world.
>

Oh! I did not realize that. Thanks Bob.

Dave

>
> On 4/6/18 9:03 AM, David T. Lewis wrote:
> >Hi Marcel,
> >
> >Thanks for this list, it will be very helpful.
> >
> >On Fri, Apr 06, 2018 at 10:20:27AM +0200, Marcel Taeumel wrote:
> >>Hi Dave,
> >>
> >>you are right. I double-checked the remaining "sends" of World. Those are
> >>only in DiskProxy, HandMorph, and MorphicProject. Seems to be load/unload
> >>code only.
> >>
> >>Much code uses ActiveWorld to trigger a UI cycle, which can be another
> >>issue to solve in the future. So, we see "ActiveWorld doOneCycleNow". It
> >>should be "Project current world doOneCycleNow" because it is
> >>Project-local. See MorphicProject >> #spawnNewProcess. Even if you think
> >>in terms of worlds-in-worlds.
> >>
> >>There are cases where "ActiveWorld" has the same problem as "World" such
> >>as in "ActiveWorld center". So "Project current world center" or even
> >>"self currentWorld" would be the fix -- even for class-side methods.
> >>
> >>For checks (in Morphs) like "self isInWorld ifTrue: [self world] ifFalse:
> >>[ActiveWorld]", ActiveWorld could also be "self currentWorld". Note that
> >>it does not make sense to override #currentWorld for Morph because the
> >>dynamic world (-in-world) scope is different from where the morph is
> >>actually contained.
> >>
> >That gives me an idea.
> >
> >It seems that, by design, a Morph is not required to know its world.
> >But we have a number of places where senders are doing world ifNil
> >checks, and if all of those checks are doing basically the same thing
> >"if I do not know the world, then use Project current world as default")
> >then we could move the responsibility to Morph and get rid of the
> >conditional checks elsewhere.
> >
> >So, instead of this:
> >
> >Morph>>world
> > ^owner isNil ifTrue: [nil] ifFalse: [owner world]
> >
> >It could be this instead:
> >
> >Morph>>world
> > owner ifNotNil: [ ^owner world ].
> > ^Project current world
> >
> >
> >
> >>Menu or halo invocation like "aMenu popUpEvent: ActiveEvent in:
> >>ActiveWorld" should be changed to use "self currentEvent" and "self
> >>currentWorld".
> >>
> >>"ActiveWorld restoreMorphicDisplay" should be rewritten to use the
> >>Project API: "Project current invalidate" or "Project current invalidate;
> >>restore" or "Project current displaySizeChanged".
> >>
> >>Best,
> >>Marcel
> >>
> >>
> >>
> >>
> >>
> >>Am 06.04.2018 05:12:48 schrieb David T. Lewis <[hidden email]>:
> >>On Thu, Apr 05, 2018 at 10:59:07AM +0200, Marcel Taeumel wrote:
> >>>Well, "ActiveWorld" is a dynamic variable that provides dynamic scope.
> >>>Just like "ActiveEvent" and "ActiveHand". Useful and powerful in some
> >>>cases. To be applied with caution. Yet, we have no alternative at the
> >>>moment. Personally, I think we do not need any.
> >>>
> >>>"World" is a global variable that we do not need anymore since the
> >>>addition of "Project" and the projects concept some time ago.
> >>>
> >>>Then, each visible morph has its own reference to a world. Usually, code
> >>>should refer to this world when passing an instance as message argument.
> >>>
> >>>---
> >>>
> >>>Currently, we have 6 senders of "World" left. We should make it 0.
> >>There should 0 senders of "World" already. The results of
> >>#browseAllCallsOn:
> >>are misleading, is that what you are looking at?
> >>
> >>I am seeing this:
> >>
> >>(CompiledMethod allInstances select: [ :e |
> >>(e literals select: [ :lit | (lit isKindOf: Global)
> >>and: [lit key == #World]]) isEmpty not]) size ==> 0
> >>
> >>
> >>>We also have 219 senders of "ActiveWorld" left. We should reduce that
> >>>number to 10 or so in the core Morphic framework. Most of the other
> >>>cases do not require ActiveWorld.
> >>>
> >>Yes!
> >>
> >>(CompiledMethod allInstances select: [ :e |
> >>(e literals select: [ :lit | (lit isKindOf: Global)
> >>and: [lit key == #ActiveWorld]]) isEmpty not]) size ==> 219
> >>
> >>
> >>I think that should be the next thing to go after. But I am not clear on
> >>the meanings. Before actually changing anything, I would want to try to
> >>get a clear understanding of the intended meaning of "ActiveWorld" and how
> >>it differs from "World". In particular I would want to be able to explain
> >>the cases where ActiveWorld is something other than Project current world.
> >>
> >>I suspect (but I am not sure) that these cases will be related to
> >>world-in-world
> >>handling, and that most other references to ActiveWorld are not really
> >>necessary
> >>as you are suggesting.
> >>
> >>Maybe Bob Arning can give us some guidance here if it is not clear.
> >>
> >>Dave
> >>
> >>
> >
>

Frank Shearar-3

Re: The Trunk: Morphic-cmm.1408.mcz

In reply to this post by Hannes Hirzel

On 6 April 2018 at 02:49, H. Hirzel <[hidden email]> wrote:

On 4/6/18, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
> 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; [hidden email]; http://www.rowledge.org/tim
>>> Strange OpCodes: CRN: Compare to Random Number
>>>
>>>
>>>
>>>
>>
>
>