Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Sophie424

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

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

Edgar J. De Cleene

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

El 1/3/08 3:05 PM, "itsme213" <[hidden email]> escribió:

> 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
>

Sophie:

You need find "local" senders or implementors ?
Look on "more" of regular menu for browsed methods.

You wish look only *your* stuff ?
Use MonticelloBrowser

Next question ?

Edgar (from a super heated place of World - aka Rosario - Argentina)

Zulq Alam-2

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

In reply to this post by Sophie424

Hi Sophie,

You can restrict the scope of refactorings using the "open environment"
menu item in the class context menu. You may have seen it above
"refactor class", "refactor class variable", etc.

This will open a new browser in which refactorings will only apply to
the selected environment.

To restrict the scope to the current category, chose "package". There
are other options you may find useful like "class hierarchy".

Regards,
Zulq.

itsme213 wrote:
> - 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.

Sophie424

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

In reply to this post by Edgar J. De Cleene

"Edgar J. De Cleene" <[hidden email]> wrote

> You need find "local" senders or implementors ?
> Look on "more" of regular menu for browsed methods.
> You wish look only *your* stuff ?
> Use MonticelloBrowser

Hi Edgar,

I looked again and still did not find anything that let me scope the results
of {senders, implementers, re-factoring, ...} to my categories or Mcz
package. Could you tell me how to do this?

Thanks - Sophie

Edgar J. De Cleene

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

El 1/3/08 5:26 PM, "itsme213" <[hidden email]> escribió:

> Hi Edgar,
>
> I looked again and still did not find anything that let me scope the results
> of {senders, implementers, re-factoring, ...} to my categories or Mcz
> package. Could you tell me how to do this?
>
> Thanks - Sophie

I recent load and try on 3.10 the Fireworks project

http://www.lazarevic.de/download/squeak/fireworks.002.pr

Load it in you Squeak3.10.gamma.7159.image, you should have fun when learn
some.

I select Fireworks , Rocket, displayOn:at:
If at this point I select "senders of (n)", all in image shows.
But if click in "more", I could find "local sender of"

If I decide focus only in this , I use MonticelloBrowser.
Clear your World into the Squeak image and load the tape.
It's not perfect , but you get the idea, don't you ?

Contrary to colleagues here say , you could end with a working app in Squeak
without deep Smalltalk or very clear ideas.

The image is your clay, give us a gorgeous pot :=)

Edgar

Picture 5.png (58K) Download Attachment

HowToMC.tape (26K) Download Attachment

Sophie424

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

In reply to this post by Zulq Alam-2

Hi Zulq,

> You can restrict the scope of refactorings using the "open environment"
> menu item in the class context menu. You may have seen it above "refactor
> class", "refactor class variable", etc.

Fantastic! Seems slightly buggy (I got several #doesNotUnderstand:
#includesCategory) but I can see this becoming my default browser.

Since re-factoring operations are scoped in this browser, I tried
Senders/Implementors in the same scoped browser and found them global again
(at least I could not find a way). Shouldn't all of these be consistently
scoped?

Thanks,

Sophie

Sophie424

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

In reply to this post by Zulq Alam-2

"Zulq Alam" <[hidden email]> wrote in message

> You can restrict the scope of refactorings using the "open environment"
> menu item in the class context menu.

What are the options
"composition: union | intersection"
that sometimes appear when you try to open this browser?

- Sophie

stephane ducasse

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

In reply to this post by Sophie424

lukas implemented a scoping refactoring browser. It is yellow and all
your refactoring will work on the context you create.
I do not remember where to load it.

stef

On 3 janv. 08, at 19:05, itsme213 wrote:

> 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
>
>
>
>
>

Zulq Alam-2

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

In reply to this post by Sophie424

I get those bugs too. Not sure about the status of this functionality. I
just discovered it myself.

Not sure whether the senders / implementors menu items scope should
match the current browser scope. That's probably because I don't like
the idea of scoped browsers. I'd prefer targeted menu options and prompts.

For example, if I try to rename #at:put: in my class, rather than be
presented with yes / no prompt to continue, more options could be
provided like "package" or "hierarchy only". As it stands the "This will
modify X implementors. Do you want to proceed?" dialogue is really just
telling you how much of a bad move you're making.

Anyway, an easy way to view package senders / implementors isn't
available (unless I've missed it?). I've wanted this for a while so I've
created the attached change set to add "package implementors" and
"package senders" menu items.

It's my first time adding stuff to the OmniBrowser so would appreciate
any comments on the idea and implementation.

Thanks,
Zulq.

itsme213 wrote:

> Hi Zulq,
>
>> You can restrict the scope of refactorings using the "open environment"
>> menu item in the class context menu. You may have seen it above "refactor
>> class", "refactor class variable", etc.
>
> Fantastic! Seems slightly buggy (I got several #doesNotUnderstand:
> #includesCategory) but I can see this becoming my default browser.
>
> Since re-factoring operations are scoped in this browser, I tried
> Senders/Implementors in the same scoped browser and found them global again
> (at least I could not find a way). Shouldn't all of these be consistently
> scoped?
>
> Thanks,
>
> Sophie
>
>
>
>
>

'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 4 January 2008 at 12:32:23 pm'!
Smalltalk renameClassNamed: #OBCmdBrowseCategoryImplementors as: #OBCmdBrowsePackageImplementors!
OBCmdBrowseList subclass: #OBCmdBrowsePackageImplementors
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Commands'!
OBCmdBrowseList subclass: #OBCmdBrowsePackageSenders
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Commands'!
Smalltalk renameClassNamed: #OBCategoryImplementorsBrowser as: #OBPackageImplementorsBrowser!
OBImplementorsBrowser subclass: #OBPackageImplementorsBrowser
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Browsers'!
OBSendersBrowser subclass: #OBPackageSendersBrowser
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Browsers'!
Smalltalk renameClassNamed: #OBShowCategoryImplementors as: #OBShowPackageImplementors!
OBNavigate subclass: #OBShowPackageImplementors
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Announcements'!
OBNavigate subclass: #OBShowPackageSenders
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'OB-Standard-Announcements'!

!OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:47'!
announcementClass
^ OBShowPackageImplementors! !

!OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:14'!
isActive
^ (target isKindOf: OBMethodNode) and: [requestor isSelected: target]! !

!OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:49'!
label
^ 'package implementors'! !

!OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:55'!
announcementClass
^ OBShowPackageSenders! !

!OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:54'!
isActive
^ (target isKindOf: OBMethodNode) and: [requestor isSelected: target]! !

!OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:55'!
label
^ 'package senders'! !

!OBCodeBrowser methodsFor: 'commands' stamp: 'za 1/4/2008 11:48'!
cmdBrowseCategoryImplementors
^ OBCmdBrowsePackageImplementors! !

!OBCodeBrowser methodsFor: 'commands' stamp: 'za 1/4/2008 11:55'!
cmdBrowseCategorySenders
^ OBCmdBrowsePackageSenders! !

!OBMethodNode methodsFor: 'private' stamp: 'za 1/4/2008 11:56'!
packageImplementorsOf: aSelector
^ ((PackageOrganizer default packageOfClass: theClass) classes
select: [:eachClass | eachClass includesSelector: aSelector ])
collect: [:eachClass | OBMethodNode on: aSelector inClass: eachClass]! !

!OBMethodNode methodsFor: 'private' stamp: 'za 1/4/2008 12:23'!
packageSendersOf: aSelector
| special byte classes senders |
special := Smalltalk hasSpecialSelector: aSelector ifTrueSetByte: [:b | byte := b].
classes := (PackageOrganizer default packageOfClass: theClass) classes.
senders := OrderedCollection new.
classes do: [:eachClass |
senders addAll: ((Preferences thoroughSenders
ifTrue: [
eachClass
thoroughWhichSelectorsReferTo: aSelector
special: special
byte: byte]
ifFalse: [
eachClass
whichSelectorsReferTo: aSelector
special: special
byte: byte])
collect: [:eachSymbol | eachClass -> eachSymbol])].
^ senders collect: [:eachAssociation | OBMethodNode on: eachAssociation value inClass: eachAssociation key]
! !

!OBMethodNode methodsFor: 'navigating' stamp: 'za 1/4/2008 11:45'!
packageImplementors
^ self packageImplementorsOf: selector! !

!OBMethodNode methodsFor: 'navigating' stamp: 'za 1/4/2008 11:49'!
packageSenders
^ self packageSendersOf: selector! !

!OBPackageImplementorsBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:45'!
defaultMetaNode
^ self implementorsNav: #packageImplementors! !

!OBPackageImplementorsBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:46'!
title
^ 'Package Implementors of'! !

!OBPackageSendersBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:52'!
defaultMetaNode
^self sendersNav: #packageSenders.
! !

!OBPackageSendersBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:52'!
title
^'Package Senders of'
! !

!OBShowPackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:46'!
browserClass
^ OBPackageImplementorsBrowser! !

!OBShowPackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:47'!
noChildrenMessage
^ 'no package implementors'! !

!OBShowPackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:53'!
browserClass
^ OBPackageSendersBrowser! !

!OBShowPackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:54'!
noChildrenMessage
^ 'no package senders'! !

!OBPackageImplementorsBrowser class reorganize!
('configuration' defaultMetaNode title)
!

Zulq Alam-2

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

In reply to this post by Sophie424

I think you get this when you open an environment from an environment
browser. It allows you to chose how the new environment should be
created with respect to the current environment, i.e. should it be union
or an intersection with the current environment.

itsme213 wrote:

> "Zulq Alam" <[hidden email]> wrote in message
>
>> You can restrict the scope of refactorings using the "open environment"
>> menu item in the class context menu.
>
> What are the options
> "composition: union | intersection"
> that sometimes appear when you try to open this browser?
>
> - Sophie
>
>
>
>
>

Sophie424

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

In reply to this post by Zulq Alam-2

"Zulq Alam" <[hidden email]> wrote in message

> Anyway, an easy way to view package senders / implementors isn't
> available (unless I've missed it?). I've wanted this for a while so I've
> created the attached change set to add "package implementors" and
> "package senders" menu items.

Thank you very much!!

Damien Cassou-3

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

In reply to this post by Zulq Alam-2

Hi Zulq,

can you please post that directly to the Monticello repository
source.wiresong.ca/ob with a useful comment?

Then, people will be able to review it more easily.

Thank you

On Jan 4, 2008 1:53 PM, Zulq Alam <[hidden email]> wrote:

> I get those bugs too. Not sure about the status of this functionality. I
> just discovered it myself.
>
> Not sure whether the senders / implementors menu items scope should
> match the current browser scope. That's probably because I don't like
> the idea of scoped browsers. I'd prefer targeted menu options and prompts.
>
> For example, if I try to rename #at:put: in my class, rather than be
> presented with yes / no prompt to continue, more options could be
> provided like "package" or "hierarchy only". As it stands the "This will
> modify X implementors. Do you want to proceed?" dialogue is really just
> telling you how much of a bad move you're making.
>
> Anyway, an easy way to view package senders / implementors isn't
> available (unless I've missed it?). I've wanted this for a while so I've
> created the attached change set to add "package implementors" and
> "package senders" menu items.
>
> It's my first time adding stuff to the OmniBrowser so would appreciate
> any comments on the idea and implementation.
>
> Thanks,
> Zulq.
>
>
> itsme213 wrote:
> > Hi Zulq,
> >
> >> You can restrict the scope of refactorings using the "open environment"
> >> menu item in the class context menu. You may have seen it above "refactor
> >> class", "refactor class variable", etc.
> >
> > Fantastic! Seems slightly buggy (I got several #doesNotUnderstand:
> > #includesCategory) but I can see this becoming my default browser.
> >
> > Since re-factoring operations are scoped in this browser, I tried
> > Senders/Implementors in the same scoped browser and found them global again
> > (at least I could not find a way). Shouldn't all of these be consistently
> > scoped?
> >
> > Thanks,
> >
> > Sophie
> >
> >
> >
> >
> >
>
> 'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 4 January 2008 at 12:32:23 pm'!
> Smalltalk renameClassNamed: #OBCmdBrowseCategoryImplementors as: #OBCmdBrowsePackageImplementors!
> OBCmdBrowseList subclass: #OBCmdBrowsePackageImplementors
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Commands'!
> OBCmdBrowseList subclass: #OBCmdBrowsePackageSenders
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Commands'!
> Smalltalk renameClassNamed: #OBCategoryImplementorsBrowser as: #OBPackageImplementorsBrowser!
> OBImplementorsBrowser subclass: #OBPackageImplementorsBrowser
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Browsers'!
> OBSendersBrowser subclass: #OBPackageSendersBrowser
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Browsers'!
> Smalltalk renameClassNamed: #OBShowCategoryImplementors as: #OBShowPackageImplementors!
> OBNavigate subclass: #OBShowPackageImplementors
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Announcements'!
> OBNavigate subclass: #OBShowPackageSenders
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'OB-Standard-Announcements'!
>
> !OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:47'!
> announcementClass
> ^ OBShowPackageImplementors! !
>
> !OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:14'!
> isActive
> ^ (target isKindOf: OBMethodNode) and: [requestor isSelected: target]! !
>
> !OBCmdBrowsePackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:49'!
> label
> ^ 'package implementors'! !
>
>
> !OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:55'!
> announcementClass
> ^ OBShowPackageSenders! !
>
> !OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:54'!
> isActive
> ^ (target isKindOf: OBMethodNode) and: [requestor isSelected: target]! !
>
> !OBCmdBrowsePackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:55'!
> label
> ^ 'package senders'! !
>
>
> !OBCodeBrowser methodsFor: 'commands' stamp: 'za 1/4/2008 11:48'!
> cmdBrowseCategoryImplementors
> ^ OBCmdBrowsePackageImplementors! !
>
> !OBCodeBrowser methodsFor: 'commands' stamp: 'za 1/4/2008 11:55'!
> cmdBrowseCategorySenders
> ^ OBCmdBrowsePackageSenders! !
>
>
> !OBMethodNode methodsFor: 'private' stamp: 'za 1/4/2008 11:56'!
> packageImplementorsOf: aSelector
> ^ ((PackageOrganizer default packageOfClass: theClass) classes
> select: [:eachClass | eachClass includesSelector: aSelector ])
> collect: [:eachClass | OBMethodNode on: aSelector inClass: eachClass]! !
>
> !OBMethodNode methodsFor: 'private' stamp: 'za 1/4/2008 12:23'!
> packageSendersOf: aSelector
> | special byte classes senders |
> special := Smalltalk hasSpecialSelector: aSelector ifTrueSetByte: [:b | byte := b].
> classes := (PackageOrganizer default packageOfClass: theClass) classes.
> senders := OrderedCollection new.
> classes do: [:eachClass |
> senders addAll: ((Preferences thoroughSenders
> ifTrue: [
> eachClass
> thoroughWhichSelectorsReferTo: aSelector
> special: special
> byte: byte]
> ifFalse: [
> eachClass
> whichSelectorsReferTo: aSelector
> special: special
> byte: byte])
> collect: [:eachSymbol | eachClass -> eachSymbol])].
> ^ senders collect: [:eachAssociation | OBMethodNode on: eachAssociation value inClass: eachAssociation key]
> ! !
>
> !OBMethodNode methodsFor: 'navigating' stamp: 'za 1/4/2008 11:45'!
> packageImplementors
> ^ self packageImplementorsOf: selector! !
>
> !OBMethodNode methodsFor: 'navigating' stamp: 'za 1/4/2008 11:49'!
> packageSenders
> ^ self packageSendersOf: selector! !
>
>
> !OBPackageImplementorsBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:45'!
> defaultMetaNode
> ^ self implementorsNav: #packageImplementors! !
>
> !OBPackageImplementorsBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:46'!
> title
> ^ 'Package Implementors of'! !
>
>
> !OBPackageSendersBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:52'!
> defaultMetaNode
> ^self sendersNav: #packageSenders.
> ! !
>
> !OBPackageSendersBrowser class methodsFor: 'configuration' stamp: 'za 1/4/2008 11:52'!
> title
> ^'Package Senders of'
> ! !
>
>
> !OBShowPackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:46'!
> browserClass
> ^ OBPackageImplementorsBrowser! !
>
> !OBShowPackageImplementors methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:47'!
> noChildrenMessage
> ^ 'no package implementors'! !
>
>
> !OBShowPackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:53'!
> browserClass
> ^ OBPackageSendersBrowser! !
>
> !OBShowPackageSenders methodsFor: 'as yet unclassified' stamp: 'za 1/4/2008 11:54'!
> noChildrenMessage
> ^ 'no package senders'! !
>
>
> !OBPackageImplementorsBrowser class reorganize!
> ('configuration' defaultMetaNode title)
> !
>
>
>
>
>

--
Damien Cassou

Lukas Renggli

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

In reply to this post by Sophie424

> > You can restrict the scope of refactorings using the "open environment"
> > menu item in the class context menu. You may have seen it above "refactor
> > class", "refactor class variable", etc.
>
> Fantastic! Seems slightly buggy (I got several #doesNotUnderstand:
> #includesCategory) but I can see this becoming my default browser.

Try the latest code, i think I fixed this.

> Since re-factoring operations are scoped in this browser, I tried
> Senders/Implementors in the same scoped browser and found them global again
> (at least I could not find a way). Shouldn't all of these be consistently
> scoped?

These are only the refactoring menus that are scoped. All the other
menus are still using the old tools and are therefor not scoped. For
example there are also two 'rename class' menus, one is the plain old
rename and the other one reactors your code in the given scope.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli

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

In reply to this post by stephane ducasse

> lukas implemented a scoping refactoring browser. It is yellow and all
> your refactoring will work on the context you create.
> I do not remember where to load it.

It is the package OB-Refactoring In the normal OB repository:

http://source.wiresong.ca/ob

Of course you need to load the Refactoring Browser first.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli

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

In reply to this post by Sophie424

> > You can restrict the scope of refactorings using the "open environment"
> > menu item in the class context menu.
>
> What are the options
> "composition: union | intersection"
> that sometimes appear when you try to open this browser?

These menus only appear when the current scope is not the full image
(which is the default). It allows you to perfom set-operations on
refectory environments. For example if you want to apply a refactoring
to all the classes of a hierarchy within a specific package (but not
to the classes outside the package) you do:

- Select the class
- Press open environment -> class hierarchy
- Select an element from your package
- Press open environment -> package -> intersection

This will intersect the package environment with the one from the hierarchy.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli

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

In reply to this post by Zulq Alam-2

> Anyway, an easy way to view package senders / implementors isn't
> available (unless I've missed it?). I've wanted this for a while so I've
> created the attached change set to add "package implementors" and
> "package senders" menu items.

Of course you can do that with the OB-Refactory tools, not very
elegant but it is doable:

- Select an element from the package
- Click open environment -> package
- Select a method
- Click open environment -> senders/implementors -> union

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Damien Cassou-3

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

In reply to this post by Lukas Renggli

On Jan 7, 2008 8:59 AM, Lukas Renggli <[hidden email]> wrote:
> > lukas implemented a scoping refactoring browser. It is yellow and all
> > your refactoring will work on the context you create.
> > I do not remember where to load it.
>
> It is the package OB-Refactoring In the normal OB repository:
>
> http://source.wiresong.ca/ob
>
> Of course you need to load the Refactoring Browser first.

Of course, it is available in squeak-dev (and -web) images.

--
Damien Cassou

Zulq Alam-2

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

In reply to this post by Damien Cassou-3

Hi Damien,

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?

Thanks,
Zulq.

Damien Cassou wrote:
> Hi Zulq,
>
> can you please post that directly to the Monticello repository
> source.wiresong.ca/ob with a useful comment?
>
> Then, people will be able to review it more easily.
>
> Thank you

Damien Cassou-3

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

On Jan 7, 2008 11:19 AM, Zulq Alam <[hidden email]> wrote:
> I'd like to do add some unit tests but am not sure what packages and
> versions I need to load?

I think you can load OB-Umbrella and it will load the rest.

--
Damien Cassou

Lukas Renggli

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

In reply to this post by Zulq Alam-2

> 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

--
Lukas Renggli
http://www.lukas-renggli.ch