On 2013-08-12, at 14:53, commits@source.squeak.org wrote:
checkForUpdates | availableUpdate updateServer | World ifNotNil: [ World install. ActiveHand position: 100@100].
- HTTPClient isRunningInBrowser
ifFalse: [^self processUpdates].
This change would always execute the case meant for the web-browser plugin. (this whole mechanism is unused anyway, even in Etoys, but still)
Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
- Bert -
On 12 August 2013 16:42, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-08-12, at 14:53, commits@source.squeak.org wrote:
checkForUpdates | availableUpdate updateServer | World ifNotNil: [ World install. ActiveHand position: 100@100].
HTTPClient isRunningInBrowserifFalse: [^self processUpdates]. availableUpdate := (AbstractLauncher extractParameters at: 'UPDATE' ifAbsent: [''] ) asInteger. availableUpdate ifNil: [^false]. updateServer := AbstractLauncher extractParameters at: 'UPDATESERVER' ifAbsent: [AbstractLauncher extractParameters at: 'UPDATE_SERVER' ifAbsent: ['Squeakland']]. Utilities setUpdateServer: updateServer. ^SystemVersion checkAndApplyUpdates: availableUpdate!This change would always execute the case meant for the web-browser plugin. (this whole mechanism is unused anyway, even in Etoys, but still)
Right. I was expecting to hear that this particular change was bad. My preference would be to rip it out completely. Or, at most, preserve it in 45Deprecated, or elsewhere. AncientUpdateStream or something.
Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
* I want Utilities to die. It's a mess of mixed responsibilities. Even were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
* With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
frank
- Bert -
On 2013-08-12, at 20:09, Frank Shearar frank.shearar@gmail.com wrote:
On 12 August 2013 16:42, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-08-12, at 14:53, commits@source.squeak.org wrote:
checkForUpdates | availableUpdate updateServer | World ifNotNil: [ World install. ActiveHand position: 100@100].
HTTPClient isRunningInBrowserifFalse: [^self processUpdates].This change would always execute the case meant for the web-browser plugin. (this whole mechanism is unused anyway, even in Etoys, but still)
Right. I was expecting to hear that this particular change was bad. My preference would be to rip it out completely. Or, at most, preserve it in 45Deprecated, or elsewhere. AncientUpdateStream or something.
Safe to delete IMHO. Nothing else depends on it so no need to deprecate.
Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
frank
Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
Discussion welcome, of course :)
- Bert -
On Mon, Aug 12, 2013 at 08:25:33PM +0200, Bert Freudenberg wrote:
On 2013-08-12, at 20:09, Frank Shearar frank.shearar@gmail.com wrote:
On 12 August 2013 16:42, Bert Freudenberg bert@freudenbergs.de wrote:
Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
frank
Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
Discussion welcome, of course :)
- Bert -
It walks like a utility and it quacks like a utility, so I think it's a Utility.
Dave
On 12 August 2013 20:10, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Aug 12, 2013 at 08:25:33PM +0200, Bert Freudenberg wrote:
On 2013-08-12, at 20:09, Frank Shearar frank.shearar@gmail.com wrote:
On 12 August 2013 16:42, Bert Freudenberg bert@freudenbergs.de wrote:
Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
frank
Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update").
Well, that's a fair point. Another solution to the problem I'm trying to address would be to move Utilities out of System.
Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
Discussion welcome, of course :)
There might be some bits lets over, but I'd like to see at least the following things moved out of Utilities: * finding pointers: Utilities >> #pointersTo:except: already lives in PointerFinder * the identification protocol in its entirety belongs in a class called something like SystemAuthor * the old update stream stuff really ought to go * move the selector hacking stuff to Symbol (#inherentSelectorForGetter:, I'm looking at you!) * any other methods that take a single parameter and construct something based on that parameter really belongs with the (expected) parameter's class. (The general case of the #inherentSelectorForGetter: example.)
- Bert -
It walks like a utility and it quacks like a utility, so I think it's a Utility.
Well, there are Utilities, and there are dumping grounds for things you can't immediately find the proper place for, and just dump it any old place.
frank
Dave
On 2013-08-12, at 21:40, Frank Shearar frank.shearar@gmail.com wrote:
On 12 August 2013 20:10, David T. Lewis lewis@mail.msen.com wrote:
It walks like a utility and it quacks like a utility, so I think it's a Utility.
Well, there are Utilities, and there are dumping grounds for things you can't immediately find the proper place for, and just dump it any old place.
frank
Dave
Apropos:
http://geek-and-poke.com/geekandpoke/2013/8/20/naming-is-key
- Bert -
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
Discussion welcome, of course :)
+1. For both actually -- We want the system packages to be more modularized, but not have to remember two things instead of just one, every time we want to make use of a "system" service.
The facade would reside in some pretty high-level package, but which one? A reason to be interested in starting to think about our package hierarchy..
As for the facades name, hm. We do already have "Smalltalk"...?
On 12 August 2013 20:39, Chris Muller asqueaker@gmail.com wrote:
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
Discussion welcome, of course :)
+1. For both actually -- We want the system packages to be more modularized, but not have to remember two things instead of just one, every time we want to make use of a "system" service.
Despite my monomania, I agree. In this particular case there is only one thing to remember - update - but for sure, higher level packages stitch together smaller, specific, goals into some overarching concern.
The facade would reside in some pretty high-level package, but which one? A reason to be interested in starting to think about our package hierarchy..
As for the facades name, hm. We do already have "Smalltalk"...?
Certainly `Smalltalk updateFromTrunk` has a nice ring to it.
frank
On 2013-08-12, at 21:45, Frank Shearar frank.shearar@gmail.com wrote:
Certainly `Smalltalk updateFromTrunk` has a nice ring to it.
frank
... unless you set a different default updateURL, as is the case in a fresh release image (or like we did for the Frank system at Viewpoints). So I wouldn't put "trunk" into the name for the general utility.
- Bert -
On 12 August 2013 21:25, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-08-12, at 21:45, Frank Shearar frank.shearar@gmail.com wrote:
Certainly `Smalltalk updateFromTrunk` has a nice ring to it.
frank
... unless you set a different default updateURL, as is the case in a fresh release image (or like we did for the Frank system at Viewpoints). So I wouldn't put "trunk" into the name for the general utility.
updateFromTrunk ^ self updateFromURL: 'http://source.squeak.org/trunk'
frank
- Bert -
On Mon, Aug 12, 2013 at 11:09 AM, Frank Shearar frank.shearar@gmail.comwrote:
On 12 August 2013 16:42, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-08-12, at 14:53, commits@source.squeak.org wrote:
checkForUpdates | availableUpdate updateServer | World ifNotNil: [ World install. ActiveHand position: 100@100].
HTTPClient isRunningInBrowserifFalse: [^self processUpdates]. availableUpdate := (AbstractLauncher extractParameters at: 'UPDATE' ifAbsent: [''] ) asInteger. availableUpdate ifNil: [^false]. updateServer := AbstractLauncher extractParameters at: 'UPDATESERVER' ifAbsent: [AbstractLauncher extractParameters at: 'UPDATE_SERVER' ifAbsent: ['Squeakland']]. Utilities setUpdateServer: updateServer. ^SystemVersion checkAndApplyUpdates: availableUpdate!This change would always execute the case meant for the web-browser
plugin. (this whole mechanism is unused anyway, even in Etoys, but still)
Right. I was expecting to hear that this particular change was bad. My preference would be to rip it out completely. Or, at most, preserve it in 45Deprecated, or elsewhere. AncientUpdateStream or something.
Also, what's wrong with "Utilities updateFromServer"? Seems to me much
nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
- I want Utilities to die. It's a mess of mixed responsibilities. Even
were that all cleaned up, it'd be a mess of mixed responsibilities delegated to better suited places. It's Bad(tm) for modularity: Utilities >> #updateFromServer makes System depend on MonticelloConfiguration, which is already dependent on System. Breaking that cycle is the whole point of this commit.
- With MCMcmUpdater >> #updateFromServer we concentrate updating in one
place.
But, Utilities>>updateFromServer is a facade with a purpose. If you go
back to 3.11 or so, you'll see that does not use Monticello at all - it used the old update server scheme (which stored change sets). (it looked something like: updateFromServer self readServerUpdatesSaveLocally: Preferences updateSavesFile updateImage: true )
I can see a future where we'll move off of Montecello - not sure which decade, but I'd be surprised if we didn't.
What if you (we?) made a new package Utilities that held these types of items? Or, better yet, what is a pragma was added that Utilities used to pickup where it should forward on the commands that are needed to perform it's tasks?
-Chris
frank
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunningham -
Chris Muller -
David T. Lewis -
Frank Shearar