prev back

how to perform typical day-to-day tasks

creating a new class

adding documentation

We suggest you stay with Smalltalk/X's philosophy of putting the documentation into empty methods under the documentation category. To do so:

adding methods

modifying existing methods

removing methods

adding/removing instance variables

Notice:

existing instances of the class will not be affected by this change. Instead, the original class will get its category changed to "obsolete" and a new class is installed under the original name. This means, that existing instances still have a valid class definition around, but methods can no longer be added/removed or changed to the old class.
In case of a changed class definition (which affects the instance layout), the system will recompile all methods that require recompilation. Have a look at the Transcript, to see what is going on.

who sends a particular message

If you are only interrested in sends within the current class and subclasses (i.e. usually in YOUR classes), you can also use the "local senders" menu function.

who implements a particular message

If you are only interrested in implementations in the current class and subclasses (i.e. usually in YOUR classes), you also can use the "local implementors" menu function.

which method is executed if I sent #foo

Use this to search up the class inheritance for an implementor of a particular message.

which methods reference/modify a particular instance variable


The menu contains entries to search locally in the current class only ("instvar refs/mods", "classvar refs/mods") and entries which descent down and also search in subclasses ("all instvar refs/mods", "all classvar refs/mods").

Since searching involves parsing the source code, these functions may take a while to show the result.

which methods reference a particular global variable

Notice:

since classes are (almost) always referenced by globals, this will also find explicit uses of classes. (for example: try searching for "Array")

The outcome of the search will be presented in a browser, which has its search-pattern preset to the globals name. Thus a search-next (i.e. CMD-F) will place the cursor to the next occurence of the string.

which methods use the current class

which method contains some string

This question is often asked, if you have some method producing a message or output to some stream, and you want to find out quickly where that happens. For example, which method is responsible for the 'compiled:' message appearing on the Transcript when methods are accepted.
There is no direct search function available for this kind of query. However, you can use the substring search functions to (at least) limit the number of methods that have to be investigated. Notice, that since all source code has to be processed, this function takes somewhat longer than other queries (senders/implementors); therefore, if you know the selector which is used, the senders function is probably better.
Also, if you have any idea of which class (or superclass) the method is contained in, use the local string search, which limits the search to some classes and is therefore faster too.

which method to use

Often, when you need some specific functionality, you know (or feel to know) that there must be some code for this in the system, but do not know exactly the name of the method.
For example, it may happen that you need some string-concatenation functionality, but do not remember what the message selector is.
To help in this situation, use the apropos function, which allows searching for a keyword in method selectors and method comments.
Try the above example, searching for 'concat'.

Notice, that this function too may take some time, since all source code has to be processed. If you know some top-class, you should limit the search (and thereby speedup the query) by using the local apropos function.
In the above example, it seems obvious that concatenation is an operation on collections - therefore you could select the Collection class and do a local apropos there.

special search browsers

You can start a browser manually, and pass a searchBlock (which is supposed to return true/false) to open a browser on any subset of methods.

For example, a browser on all methods with 3 arguments can be opened with:

    SystemBrowser browseAllSelect:[:cls :method :sel |
					sel numArgs == 3
				  ]
if you are interrested in methods with more than 10 arguments, try:
    SystemBrowser browseAllSelect:[:cls :method :sel |
					sel numArgs > 10
				  ]
or, to find all method which have 'at:' in their name:
    SystemBrowser browseAllSelect:[:cls :method :sel |
					'*[aA]t:*' match:sel
				  ]
Beside browseAllSelect:, there are other special startup messages to be found in SystemBrowsers class protocol. Have a look at them - you may find some of these useful when searching for methods.

hints & tips

mark your changed methods

when adding methods to existing system classes, you should mark them (either by name or their category) to ease finding those later.
For example, you may later want to fileout all of your added methods. This can be done automatically if all of them have a distinct category. ("fileOut-all" function in the method category list).

Starting with version 2.10.4, methods and classes include a package field. This makes it very easy, to identify classes and methods which belong to a package for fileOut. Set the current projects packageName to some unique name and use the ProjectViews "save project files" function to have them saved in your project directory.

prepare use of the stc machine code compiler

If you plan to compile your classes later to binary modules, use the "fileout-each" function instead of "fileOut" in the class category list.
This one will create separate sourcefiles for each class instead of putting all of them into one big file. The reason is that the stc-compiler (currently) cannot compile multiple classes, but requires one class per sourcefile.

use project directories

If you are working in multiple projects, define some per-project directory in the project-view. The systemBrowser will save the files into the active projects directory.

keep your sourcefiles consistent

Be careful about overwriting existing sourcefiles when filing out: since the methods source is typically extracted from some sourcefile, overwriting one of these will lead to funny results. All fileOut functions will be changed in upcoming versions to take care about this, but currently you should not fileOut into the 'source'-directory or one of the 'libXXX' directories.

Be very careful when editing existing sourcefiles with the fileBrowser or another (non-ST/X) editor. Since methods do not keep the source as a string, but instead the filename and filePosition, editing a sourcefile makes this sourceinfo invalid (you will see funny code in the systemBrowser). If you "fileOut" these methods, the resulting output file will be useless.