[squeak-dev] Reducing ActiveWorld dependencies (was: The Trunk: Morphic-cmm.1408.mcz)

Marcel Taeumel marcel.taeumel at hpi.de
Fri Apr 6 13:50:23 UTC 2018


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 <lewis at mail.msen.com>:
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
>
>

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180406/880b59d6/attachment.html>


More information about the Squeak-dev mailing list