On Tuesday, August 12, 2003, at 07:56  AM, Joshua 'Schwa' Gargus wrote:

> On Tue, Aug 12, 2003 at 02:29:11AM -0700, Colin Putney wrote:
>
>> Personally, I'd like to see something like 'self navigator' be the
>> default way of getting a SystemNavigator. Then there's lots of room 
>> for
>> overriding the default behaviour, in sort of the same way that classes
>> can specify which compiler class should be used to compile their
>> methods.
>
> I have thought that SystemNavigator provides a good core for browsing
> the capabilities of remote images.  'SystemNavigaton default' would
> answer the SystemNavigaton for the current image, and 'SystemNavigaton
> pid: processID' could return one on another Squeak instance.
>
> I suppose this could be changed a bit to accomodate your vision.
> 'self navigator' could return the class-appropriate SystemNavigation
> for the current image, and 'self navigatorForPID: processID' could
> return one for another image.
>
> Either of our approaches would be easy to move to should a need arise.
> I think that sticking with 'SystemNavigation default' is the way to
> go for 3.6.
>
> I confess that I can't think of a concrete use for your suggestion.
> Care to broaden my horizons?

Actually, I don't have an immediate use case for this either. It was 
more of a general observation that the users of SystemNavigator are all 
dev-tools of various flavours. What with the KCP, Squat, and packaging, 
the unit of development isn't universally the local image anymore. As 
Joshua notes above, we may want to develop in a remote environment 
using local tools. We may want to limit the scope of our navigation to 
a single package. Or we may want to do exotic things like send 
#allCallsOn: to an index of message sends compiled from all the 
packages on SqueakMap.

What I like about the current method of navigation is that it's split 
into two parts - obtain a navigator and then navigate. I agree with 
Andreas that 'SystemNavigator new' is a bit of an odd way to do that in 
some cases. It's more natural from an OO POV to ask a class about its 
methods than to as the system to narrow its search to a specific class. 
So I wanted a more natural way of obtaining a navigator instance.

It could be the wrong indirection, or maybe an unnecessary indirection. 
It probably is. I just think that it's silly to go to the trouble of 
separating out a clean abstraction for tracing through source code, and 
then prevent the possibility of using it polymorphically by referencing 
it through a global.

Colin