Just wanted to chime in here, that I think the use case of wanting your
development tools to work on another environment is certainly real -
I've wanted to be able to use SLint on non-filed-in code for about a
year now. The problem is that the RB looks up the classes and sources
too directly.

I still don't have suggestions on how to solve this part of the problem,
though.

Daniel

Colin Putney <cputney at wiresong.ca> wrote:
> 
> 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