The Trunk: Morphic-cmm.1408.mcz
Locked
12
12
 
|
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 ] ] ] ! |
Re: The Trunk: Morphic-cmm.1408.mcz
|
It should be "Project current world" then. Best, Marcel
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
On Tue, Apr 3, 2018 at 11:44 PM, Marcel Taeumel <[hidden email]> wrote:
But World == Project current world. Why not just World? (That's a sincere question, not an attempt to disagree)
_,,,^..^,,,_ best, Eliot |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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 |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
> 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. |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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 |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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]
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 |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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]>:
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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.2018-04-05 10:03 GMT+02:00 Marcel Taeumel <[hidden email]>:
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
In reply to this post by Nicolas Cellier
Hi Nicolas, Hi Marcel,
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.
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
In reply to this post by marcel.taeumel
Hi Marcel,
On Thu, Apr 5, 2018 at 1:59 AM, Marcel Taeumel <[hidden email]> wrote:
Agreed.
Agreed, given ActiveWorld. But then shouldn't we use ActiveWorld rather than Project current world?
Right. self world wherever possible.
Are you being sarcastic?
_,,,^..^,,,_ best, Eliot |
Reducing ActiveWorld dependencies (was: The Trunk: Morphic-cmm.1408.mcz)
|
|
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 |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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 |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
-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
|
Re: Reducing ActiveWorld dependencies (was: The Trunk: Morphic-cmm.1408.mcz)
|
|
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
|
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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 > > > > |
Re: The Trunk: Morphic-cmm.1408.mcz
|
|
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 >> >> >> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |