On Tuesday, Aug 12, 2003, at 01:18 Europe/Zurich, Andreas Raab wrote:

> Hi Guys,
>
> I was just browsing over all the senders of #deprecatedExplanation: to 
> see
> what kind of things have changed and there were a few oddities that I
> noticed.

Great!

>
> First of all, given that SystemNavigation is stateless, wouldn't it 
> make a
> lot of sense to have a global called "SystemNavigator" or somesuch 
> which you
> can send the appropriate queries to? E.g., it's somehow terribly
> inconvenient having to write "SystemNavigation new doSomething"
> (SystemNavigation>>uniqueInstance or SystemNavigation>>default are no
> better). It seems to me that having this global is really not taking 
> away
> anything but makes the functionality of SystemNavigation readily and
> conveniently available.

Ah, a Globals vs. Singleton discussion :-) For me there is two reasons 
for liking the Singleton approach over the Global Variable approach:
(a) the environment has almost no support for dealing with global 
variables. If we had a Globals browser, and support for globals in the 
inspector and the menus my argument would be much weaker :-) Maybe it 
is even there but I never saw it. Note: it is not that I cannot find 
out if I want too - you can always do that. But this argument is about 
accessibility by your 'average programmer'.
(b) I imagine that this will grow over time. Like you said in one of 
the previous mails: if you refactor an existing system and create a new 
class for some related functionality, this tends to then start to grow 
and attract more functionality. I can imagine this here as well. And in 
that case I am quite sure that sooner or later we will not be happy 
with that global variable. Note: I know, this is a kind of up-front 
decision that even might to turn out wrong. But I consider it a small 
price to pay...

Note also the whole discussion in "Design Patterns - The Smalltalk 
Companion" (pages 91 to 101). In short, the advantages of a Singleton 
over a global variable are that with a singleton you have more control 
over the instance (when it's created, how it's initialized, when it's 
released for garbage collection), as well as preventing the creation of 
multiple instances.

>
> Secondly, some of the deprecated methods I think shouldn't be 
> deprecated at
> all - most importantly those that refer to finding references to some 
> symbol
> in the scope of some class. If I want to know something about a 
> specific
> class (such as if it sends a selector, reads or writes a variable) it 
> seems
> very natural to me to ask that class about it rather than some third 
> party
> (which has a very intrusive, non-OO feel; just like poking around 
> blindly;
> really what does SystemNavigation know about B3DHardwareEngine?). It 
> seems
> to me that most of the methods involved here really ought to be 
> extension
> methods provided by SystemNavigation.
>
> Thoughts?

Always :-) These kinds of changes automatically gives rise to lots of 
discussions... Again I'll give my motivations for this (we discussed 
already a lot about these things here :-) ):
(a) For me, the major reason is what Gillad Bracha and David Ungar call 
'Stratification': meta-level facilities must be separated from 
base-level functionality. This even holds for such functionality as 
finding stuff in the scope of a class. In Strongtalk, for example, this 
is done through the concept of Mirrors. You can see this 
SystemNavigation as a kind of Mirror (in the Strongtalk sense). Why 
should Class überhaupt know about B3DHardwareEngine? That is not a 
trivial question or functionality either.
(a) If there would be a package mechanism in Squeak (an official, 
supported one), we could use that. Whether we use it to provide 
'shortcuts' to the methods on SystemNavigation, or to directly 
implement them there does not even matter. But since there is no good 
supported packaging mechanism.......

>
> Cheers,
>   - Andreas
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org