Big Tools question - Why no way to "scope" tools to less than Global?

>> I've uploaded OB-Standard-za.311.mcz.
>>
>> I'd like to do add some unit tests but am not sure what packages and
>> versions I need to load?
>
> That would be a good candidate for a separate package. I am pretty
> sure that porters to other Smalltalk dialects (GemStone) are not
> really happy about the dependency to the Squeak Package manager.
>
> Also the code is bugged, it only considers the instance-side, use
> #classesAndMetaClasses instead of just #classes.
>
> Lukas
>

> Application development in squeak Vs. Squeak development.
>
> In using all of the Squeak tools (find implementors, senders, refactoring
> browser, ...) I find that they all operate on the global squeak image
> collection of classes, methods, etc.
>
> As an application developer (as opposed to someone working on the Squeak IDE
> itself) my methods are one of:
>   1. intended to connect into the large Squeak world
>   2. produced and consumed entirely within my application
> where "My Application" is typically some class categories, or perhaps a Mcz
> package.
>
> The big problem is with #2 (to a lesser extent #1 as well): I need the tools
> to operate on a smaller defined scope of "My Application" and cannot find
> any (simple) way to do this. Examples:
>
> - I want to see all *my* implementors of #printOn: but need to browse
> through the list of all within Squeak. Needless overhead.
>
> - I want to rename *my* method #removeChild: but if #removeChild is used
> *anywhere* else in the image I cannot do it without affecting all the
> implementors. Period. I come to a dead stop with that refactoring.
>
> I know all things are dynamic in Squeak and you don't know who will call
> which implementation. I just want a way for me to say: "Please scope all
> tools searches etc. to *My Application*. Trust me. I really do want to
> ignore all others".
>
> One easy way to define scope: just limit scope to what the current browser
> is working on (which raises a separate problem, as more narrowly focused
> browsers seem to get second-class attention compared to the global System
> Browser).
>
> Are these observation accurate? Reasonable?
>
> Why is this? It seems this aspect of squeak tools are oriented more to those
> who develop squeak itself, rather than those who develop applications.
>
> Thanks - Sophie

> Application development in squeak Vs. Squeak development.
>
> In using all of the Squeak tools (find implementors, senders, refactoring
> browser, ...) I find that they all operate on the global squeak image
> collection of classes, methods, etc.
>
> As an application developer (as opposed to someone working on the Squeak IDE
> itself) my methods are one of:
>   1. intended to connect into the large Squeak world
>   2. produced and consumed entirely within my application
> where "My Application" is typically some class categories, or perhaps a Mcz
> package.
>
> The big problem is with #2 (to a lesser extent #1 as well): I need the tools
> to operate on a smaller defined scope of "My Application" and cannot find
> any (simple) way to do this. Examples:
>
> - I want to see all *my* implementors of #printOn: but need to browse
> through the list of all within Squeak. Needless overhead.
>
> - I want to rename *my* method #removeChild: but if #removeChild is used
> *anywhere* else in the image I cannot do it without affecting all the
> implementors. Period. I come to a dead stop with that refactoring.
>
> I know all things are dynamic in Squeak and you don't know who will call
> which implementation. I just want a way for me to say: "Please scope all
> tools searches etc. to *My Application*. Trust me. I really do want to
> ignore all others".
>
> One easy way to define scope: just limit scope to what the current browser
> is working on (which raises a separate problem, as more narrowly focused
> browsers seem to get second-class attention compared to the global System
> Browser).
>
> Are these observation accurate? Reasonable?
>
> Why is this? It seems this aspect of squeak tools are oriented more to those
> who develop squeak itself, rather than those who develop applications.
>
> Thanks - Sophie
>
>
>
>
>