The Trunk: Morphic-cmm.1408.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Trunk: Morphic-cmm.1408.mcz

commits-2
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 ] ] ]
  !


Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
It should be "Project current world" then.

Best,
Marcel

Am 04.04.2018 06:17:03 schrieb [hidden email] <[hidden email]>:

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




Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2


On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Wed, Apr 04, 2018 at 11:18:46AM -0700, Eliot Miranda wrote:
> On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]>
> 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


Reply | Threaded
Open this post in threaded view
|

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

timrowledge


> On 04-04-2018, at 5:30 PM, David T. Lewis <[hidden email]> wrote:
>  the World is deprecated but retained
> for convenience.

I see a strap-line for a really interesting SF story....

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Spero nos familiares mansuros. = I hope we'll still be friends.



Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Wed, Apr 04, 2018 at 05:37:45PM -0700, tim Rowledge wrote:
>
>
> > On 04-04-2018, at 5:30 PM, David T. Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by David T. Lewis
Hi David,

On Wed, Apr 4, 2018 at 5:30 PM, David T. Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
In reply to this post by Eliot Miranda-2
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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






Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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






Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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










Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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










Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Nicolas Cellier
Hi Nicolas, Hi Marcel,

On Apr 5, 2018, at 1:36 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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











Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by marcel.taeumel
Hi Marcel,

On Thu, Apr 5, 2018 at 1:59 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:

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 <[hidden email]>:
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 <[hidden email]>:



On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> 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 [hidden email] <[hidden email]>:

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














--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
In reply to this post by marcel.taeumel
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


Reply | Threaded
Open this post in threaded view
|

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

timrowledge
In reply to this post by Eliot Miranda-2

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



Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
-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 <[hidden email]>:


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





Reply | Threaded
Open this post in threaded view
|

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

marcel.taeumel
In reply to this post by David T. Lewis
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 <[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




Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
In reply to this post by marcel.taeumel
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 <[hidden email]> 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 <[hidden email]>:
>
> 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
On 4/6/18, H. Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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
>>
>>
>>
>>
>

12