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
El 1/3/08 3:05 PM, "itsme213" itsme213@hotmail.com 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:
- intended to connect into the large Squeak world
- 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)
"Edgar J. De Cleene" edgardec2001@yahoo.com.ar 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
El 1/3/08 5:26 PM, "itsme213" itsme213@hotmail.com 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
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.
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
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" me@zulq.net 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!!
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 me@zulq.net 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) !
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
On Jan 7, 2008 11:19 AM, Zulq Alam me@zulq.net 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.
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
Ok, I've uploaded OB-PackageScopedMenuItems-za.1.mcz which includes the fix for #classesAndMetaClasses.
Thanks, Zulq.
Lukas Renggli wrote:
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
Hi Zulq,
On Jan 9, 2008 1:53 PM, Zulq Alam me@zulq.net wrote:
Ok, I've uploaded OB-PackageScopedMenuItems-za.1.mcz which includes the fix for #classesAndMetaClasses.
after having used your package for some time, fixed the bugs, and if others tell me it's useful, I can add it to squeak-dev.
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
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
"Zulq Alam" me@zulq.net 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
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" me@zulq.net 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
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 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:
- intended to connect into the large Squeak world
- 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
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:
Of course you need to load the Refactoring Browser first.
Lukas
On Jan 7, 2008 8:59 AM, Lukas Renggli renggli@gmail.com 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/obOf course you need to load the Refactoring Browser first.
Of course, it is available in squeak-dev (and -web) images.
On Jan 3, 2008 7:05 PM, itsme213 itsme213@hotmail.com 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:
- intended to connect into the large Squeak world
- 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
Seems reasonable to me. I think the problem is that Squeak currently lacks the idea of a "project" found in e.g. Dolphin. Having such a concept could open other doors as well (e.g. easier deployment of .exes, etc.)
- I want to see all *my* implementors of #printOn: but need to browse
through the list of all within Squeak. Needless overhead.
Hi Sophie, this has been available in the standard image for years, but it is not in a very convenient place.
In your methods list, Shift + Right-click on the methods list. Then select "Filter message list...". Then, on the sub-menu, "messages authored by me".
If you commit the keyboard sequence to muscle-memory, e.g.,
Shift + Right-click + "f i l" + Enter + "b" + Enter
you can have the list filtered in about 1 to 2 seconds.
As for filtering by package, Diego posted a simple addition to the Filter menu last June:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117751.html
- Chris
On Jan 3, 2008 1:05 PM, itsme213 itsme213@hotmail.com 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:
- intended to connect into the large Squeak world
- 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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Damien Cassou -
Edgar J. De Cleene -
itsme213 -
Jason Johnson -
Lukas Renggli -
stephane ducasse -
Zulq Alam