Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow + windowsIn: World - windowsIn: self world satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
It should be "Project current world" then.
Best, Marcel Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org commits@source.squeak.org: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow + windowsIn: World - windowsIn: self world satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel
Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org < commits@source.squeak.org>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow
- windowsIn: World
- windowsIn: self world
satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
On Wed, Apr 04, 2018 at 11:18:46AM -0700, Eliot Miranda wrote:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
The background on this is that there are a number of global variables such as World for which the world would be a better place if they were not global ;-)
Think about a situation in which we have different kinds of projects in the image, and where one of those projects is typically active an any time, but you want to have some flexibility with respect to what you mean by "active".
So, for example, if you define the global World to refer to the PasteUpMorph that is filling your display, and maybe another global ActiveWorld that probably refers to the same thing most of the time, but maybe refers to something else if you are displaying a "world in world" at the moment, then everything works pretty well. But then if you switch over to some other kind of project, let's say MVC for the sake of illustration, then what do those globals mean now? And what if you want to be in a project that is not Morphic or MVC, but something else such as a SqueakShellProject?
Global variables such as World are very convenient, but they are a barrier to some of the modularization that you might want to have, so it is overall a good idea not to let different parts of the system (e.g. MVC, Morphic, Morphic3, etc) be directly dependent on them.
With respect to World, I recently did a slew of changes to get rid of the direct dependencies on that global variable. The current state is that if you remove that variable completely from the system dictionary, the system still works. The variable itself is retained (and updated at the appropriate times) because it is a well-known name, and because it is an important convenience from the point of view of people evaluating expressions in a workspace.
Unfortunately, we have no way of marking globals as "deprecated", but if we had such a thing, I would say the World is deprecated but retained for convenience.
Dave
On 04-04-2018, at 5:30 PM, David T. Lewis lewis@mail.msen.com wrote: the World is deprecated but retained for convenience.
I see a strap-line for a really interesting SF story....
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Spero nos familiares mansuros. = I hope we'll still be friends.
On Wed, Apr 04, 2018 at 05:37:45PM -0700, tim Rowledge wrote:
On 04-04-2018, at 5:30 PM, David T. Lewis lewis@mail.msen.com wrote: the World is deprecated but retained for convenience.
I see a strap-line for a really interesting SF story....
Yikes.
Apparently I spent too much time working on that global World elimination project, and I have somehow become desensitized to the grim implications of my words ;-)
Dave
Hi David,
On Wed, Apr 4, 2018 at 5:30 PM, David T. Lewis lewis@mail.msen.com wrote: [snip]
Unfortunately, we have no way of marking globals as "deprecated", but if we had such a thing, I would say the World is deprecated but retained for convenience.
Hmmm, that's really interesting. In VisualWorks, variable bindings are not dereferenced directly, but instead sent value and value:. This makes it possible to deprecate globals. I'll put making a modification to the VM on the list which would be something like implementing a special kind of lookup cache for dereferencing bindings that would become proper sends for "exotic" kinds of binding. Then we could add DeprecatedBinding and one would be able, as one should, to deprecate bindings.
_,,,^..^,,,_ best, Eliot
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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
-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@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
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@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@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
On 4/6/18, H. Hirzel hannes.hirzel@gmail.com wrote:
Marcel,
is it possible to elaborate what is meant with 'Dynamic variable'?
A good place to do so here
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 marcel.taeumel@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@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
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 hannes.hirzel@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
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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
On 4/6/18, Marcel Taeumel marcel.taeumel@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@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
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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
On 6 April 2018 at 02:49, H. Hirzel hannes.hirzel@gmail.com wrote:
On 4/6/18, Marcel Taeumel marcel.taeumel@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@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
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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CRN: Compare to Random Number
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel Am 04.04.2018 20:18:58 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org [mailto:commits@source.squeak.org] <commits@source.squeak.org [mailto:commits@source.squeak.org]>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz [http://source.squeak.org/trunk/Morphic-cmm.1408.mcz]
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow + windowsIn: World - windowsIn: self world satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
--
_,,,^..^,,,_
best, Eliot
But we replaced a global World by another global Project. It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel
Am 04.04.2018 20:18:58 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel
Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org < commits@source.squeak.org>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow
- windowsIn: World
- windowsIn: self world
satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
-- _,,,^..^,,,_ best, Eliot
Ah, sorry. In my mind, I separate classes from other globals. I was referring to these other globals. Classes are fine -- even though one should always evaluate the need for any new class in the system, too.
Best, Marcel Am 05.04.2018 09:59:29 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: But we replaced a global World by another global Project.
It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel Am 04.04.2018 20:18:58 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org [mailto:commits@source.squeak.org] <commits@source.squeak.org [mailto:commits@source.squeak.org]>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz [http://source.squeak.org/trunk/Morphic-cmm.1408.mcz]
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow + windowsIn: World - windowsIn: self world satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
--
_,,,^..^,,,_
best, Eliot
Hi Marcel, yes, but the goal is rather to get rid of a global state (The single active World) and replace with a specific world passed by message or whatever. In Project current world, we have messages that provide indirection levels instead of a direct access by global scope. This is maybe more robust to future change (in balance with less simplicity). But we still have a global state (The active world). Maybe that's what Eliot was meaning (but I should rather let Eliot speak).
2018-04-05 10:03 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Ah, sorry. In my mind, I separate classes from other globals. I was referring to these other globals. Classes are fine -- even though one should always evaluate the need for any new class in the system, too.
Best, Marcel
Am 05.04.2018 09:59:29 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>: But we replaced a global World by another global Project. It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel
Am 04.04.2018 20:18:58 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel
Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org < commits@source.squeak.org>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow
- windowsIn: World
- windowsIn: self world
satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
-- _,,,^..^,,,_ best, Eliot
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. 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.
---
Dynamically-scoped variables are great for writing robust tests in such a primarily state-based environment. :-)
Best, Marcel Am 05.04.2018 10:36:57 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi Marcel,
yes, but the goal is rather to get rid of a global state (The single active World) and replace with a specific world passed by message or whatever.
In Project current world, we have messages that provide indirection levels instead of a direct access by global scope.
This is maybe more robust to future change (in balance with less simplicity).
But we still have a global state (The active world).
Maybe that's what Eliot was meaning (but I should rather let Eliot speak).
2018-04-05 10:03 GMT+02:00 Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
Ah, sorry. In my mind, I separate classes from other globals. I was referring to these other globals. Classes are fine -- even though one should always evaluate the need for any new class in the system, too.
Best, Marcel Am 05.04.2018 09:59:29 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com [mailto:nicolas.cellier.aka.nice@gmail.com]>: But we replaced a global World by another global Project.
It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel Am 04.04.2018 20:18:58 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org [mailto:commits@source.squeak.org] <commits@source.squeak.org [mailto:commits@source.squeak.org]>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz [http://source.squeak.org/trunk/Morphic-cmm.1408.mcz]
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow + windowsIn: World - windowsIn: self world satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
--
_,,,^..^,,,_
best, Eliot
Hi Marcel,
On Thu, Apr 5, 2018 at 1:59 AM, Marcel Taeumel marcel.taeumel@hpi.de 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.
Agreed.
"World" is a global variable that we do not need anymore since the addition of "Project" and the projects concept some time ago.
Agreed, given ActiveWorld. But then shouldn't we use ActiveWorld rather than Project current world?
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.
Right. self world wherever possible.
Currently, we have 6 senders of "World" left. We should make it 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.
Dynamically-scoped variables are great for writing robust tests in such a primarily state-based environment. :-)
Are you being sarcastic?
Best, Marcel
Am 05.04.2018 10:36:57 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>: Hi Marcel, yes, but the goal is rather to get rid of a global state (The single active World) and replace with a specific world passed by message or whatever. In Project current world, we have messages that provide indirection levels instead of a direct access by global scope. This is maybe more robust to future change (in balance with less simplicity). But we still have a global state (The active world). Maybe that's what Eliot was meaning (but I should rather let Eliot speak).
2018-04-05 10:03 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Ah, sorry. In my mind, I separate classes from other globals. I was referring to these other globals. Classes are fine -- even though one should always evaluate the need for any new class in the system, too.
Best, Marcel
Am 05.04.2018 09:59:29 schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>: But we replaced a global World by another global Project. It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel
Am 04.04.2018 20:18:58 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel
Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org < commits@source.squeak.org>: Chris Muller uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-cmm.1408.mcz
==================== Summary ====================
Name: Morphic-cmm.1408 Author: cmm Time: 3 April 2018, 11:15:51.160237 pm UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 Ancestors: Morphic-cmm.1407
The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). Fixes the Reuse Windows preference.
=============== Diff against Morphic-cmm.1407 ===============
Item was changed: ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- anyOpenWindowLikeMe
self class reuseWindows ifFalse: [ ^Array empty ]. ^ SystemWindow
- windowsIn: World
- windowsIn: self world
satisfying: [ : each | each model class = self model class and: [ (each model respondsTo: #representsSameBrowseeAs:) and: [ each model representsSameBrowseeAs: self model ] ] ] !
-- _,,,^..^,,,_ best, Eliot
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
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.
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 lewis@mail.msen.com: 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
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 lewis@mail.msen.com: 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
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@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
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 lewis@mail.msen.com: 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
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 lewis@mail.msen.com: 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
Hi Nicolas, Hi Marcel,
On Apr 5, 2018, at 1:36 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Marcel, yes, but the goal is rather to get rid of a global state (The single active World) and replace with a specific world passed by message or whatever. In Project current world, we have messages that provide indirection levels instead of a direct access by global scope. This is maybe more robust to future change (in balance with less simplicity). But we still have a global state (The active world). Maybe that's what Eliot was meaning (but I should rather let Eliot speak).
Right. The two are the same; they have exactly the same result (except when changing worlds because the two variables World and CurrentProject cannot be changed at exactly the same time). One can put a breakpoint on world but not intercede with World, but that's fixable, and not necessarily useful. So if the two are effectively the same why bother with a longer form? There used to be a time when "let's get rid of globals" forced us to use SmalltalkImage current instead of Smalltalk, and we're still stuck with self systemNavigation. The Smalltalk vm, Smalltalk navigation, Smalltalk image approach I like much more. Project current world kind of breaks the law of Demeter. If there's something wrong (for me) it's that World sounds like a class; TheWorld is better.
This is about brevity and modularity, but also about the system's architecture. If the system contains a singleton (and it contains a few non-class singletons and /lots/ of class singletons) and that singleton is widely used (meaning it is global, not scopable to a class) and accessing it though a class isn't convenient (Project current is pretty convenient) then why not access it as a global instead of via a message sending path from some other variable? Provided the name is good and the global refers to something fundamental to the system's architecture then I don't see the harm.
If World were a class then World current would be convenient and TheWorld wouldn't be compelling.
But isn't this about more? If it is about the architecture of Morphic worlds and we have a world per project, and in Nebraska potentially shared worlds, and in general can come up with any number of worlds, active at the same time, then if we want, say, to open a window like another in a shared world, not the current world, then the morph should be saying self world /not/ World or Project current world. And arguably self myWorld. But the constraint that imposes is that a morph can't be in two worlds at once. If you want morphs to be in more than one world at once then that won't work.
So instead of focusing on the surface issue, which should be determined by readability and writability concerns, what's the deeper issue? Is self world right? If so, use it.
2018-04-05 10:03 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Ah, sorry. In my mind, I separate classes from other globals. I was referring to these other globals. Classes are fine -- even though one should always evaluate the need for any new class in the system, too.
Best, Marcel
Am 05.04.2018 09:59:29 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
But we replaced a global World by another global Project. It's more about limiting the number of globals to a set of more universal roots?
2018-04-05 9:42 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Because with "Project current world" we have messaging (#current, #world) as point of variation. Pure state access via globals is too limited.
Best, Marcel
Am 04.04.2018 20:18:58 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
It should be "Project current world" then.
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
Best, Marcel > Am 04.04.2018 06:17:03 schrieb commits@source.squeak.org commits@source.squeak.org: > > Chris Muller uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-cmm.1408.mcz > > ==================== Summary ==================== > > Name: Morphic-cmm.1408 > Author: cmm > Time: 3 April 2018, 11:15:51.160237 pm > UUID: 35b2e2ad-c421-4510-a635-774bfd84e597 > Ancestors: Morphic-cmm.1407 > > The responsibility of #anyOpenWindowLikeMe, as indicated by its name, is to look in the actual World world for any open window like the receiver, not the receivers #world (which is nil, because because we wish to look in the real world first!). > Fixes the Reuse Windows preference. > > =============== Diff against Morphic-cmm.1407 =============== > > Item was changed: > ----- Method: SystemWindow>>anyOpenWindowLikeMe (in category 'open/close') ----- > anyOpenWindowLikeMe > > self class reuseWindows ifFalse: [ ^Array empty ]. > ^ SystemWindow > + windowsIn: World > - windowsIn: self world > satisfying: > [ : each | > each model class = self model class > and: [ (each model respondsTo: #representsSameBrowseeAs:) > and: [ each model representsSameBrowseeAs: self model ] ] ] > !
-- _,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
commits＠source.squeak.org -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
H. Hirzel -
Marcel Taeumel -
Nicolas Cellier -
tim Rowledge