[prev] [up] [next]

Code Editing

The code editor is modeless. It does not matter how text came into the codeview (i.e. if you typed it from scratch, copy-pasted existing code into it or modified any already shown code). Whenever you "accept" (use the menu function "accept" or the keyboard shortcut), depending on the current context, either a class- or a method-change is performed. It is therefore legan and common to select an existing method and use that as a base for new code - simply modify the methods name before accepting.

Intelligent Editing

The editor supports code completion (via the "CTRL-Space" key combination) and sniplet expansion (via "ALT-Space").

Also many rewrite and refactoring functions are found on the codeview popup menu (especially: the code menu, which is reached quickly by pressing the "Shift" key while clicking)

Syntax Highlighting

By default, text is syntax-highlighted according to the current classes programming language (currently, Smalltalk, JavaScript or Ruby are supported). The syntax colors and emphasis can be customized via the Launcher's settings dialog ("System"-"Settings"-"Tools"-"Editor"-"Syntax Colors").

Also many rewrite and refactoring functions are found on the codeview popup menu (especially: the code menu, which is reached quickly by pressing the "Shift" key while clicking)

New Code Editor (Code Editor 2)

Starting with vsn6.2, the new codeview implementation also shows line numbers and allows for breakpoints to be set/cleared by clicking in the line number area.

It also gives you quick implementor/sender navigation (press "Ctrl-LeftMouseButton" and "Ctrl-RightMouseButton" while the mouse is over a message selector).

The new code editor is still considered to be experimental; therefore, it has to be explicitly enabled via the launchers "tools"-"code editor 2" settings menu.

Accepting

Performing "accept" in the code view (we say ``accepting'') will behave different, depending on the last action in one of the list views. In general, accepting always affects the aspect shown in the code view.
This means that accept will:

The one exception is the full class browser: accept may affect all of the above, since it rereads all of the text shown in the codeview (actually a filein).

Unless your changed code has been accepted, no changes are made to the actual method or class. If you want to change your mind, and go back to the original (actually: the last accept) version after editing for a while, simple click on the method (in the methodlist) after a method change or the class (in the classList) after a definition change.

In addition, the new browser keeps a history of the last few changes made, and allows undo via the operations menu.

Reacting to Changes Made in Other Browsers

If a method being shown is changed by some other part of the system (another browser, a fileIn, or a repository update made in another browser), the displayed source code will be automatically updated, UNLESS you have modified the code.
In this case, the modified text will still be shown, but emphasized with a red color, to visualize the fact, that the shown code is not up-to-date.

Recompilation after a Class Change

Changing a classes instance- or classInstance variable definition may require a recompile of some or all methods (also often in subclasses).
(the recompile is required, since named instance variables are accessed via their index in the byteCode - thus, without recompilation, old methods code would refer to wrong instvars).
Smalltalk tries to recompile only the minimum set of methods, but still, this recompilation may take some time.

Notice, that when you add or remove instance variables to/from a class description and accept, the system will actually create a new class instead of changing the old one, and recompile the original methods in the context of the new definition (the same is done when class instance variables are added or removed).

The original class is still physically around, but no longer accessable by name. It is called an anonymous class and has a category of "obsolete".
The reason for doing this is that existing instances of the class still need their valid class for proper operation (which is the old one, NOT the new one); keep in mind that all specification (i.e. number of instance variables etc.) and protocol (i.e. the list of selectors) are defined in an objects class - therefore, old instances would be in big trouble without a valid class, once they receive a message.

After such a change, the old (anonymous) class is no longer editable by the systemBrowser. The following scenario should give you more insight on this:

consider a view class of yours, of which an instance exists and is visible on the screen

now you add an instance variable "foo" to its class description

this creates a new class (with the original name), and removes the old one from the name tables; the old class is still around but not reachable by the old name. However, if you inspect that class, it will show its old name and a category of "obsolete.

Old instances are therefore no longer affected by any changes in the browser, thus any changes will only make sense for new instances.

Why is this so ?

There are basically 2 other possible solutions to handling this situation:
  1. do not allow a class definition change as long as there are instances
    this would make it impossible, to change things like ScrollBars, TextViews and almost any other class in the system.

  2. convert instances
    this means that existing instances have to either get new fields added (which default value ?) or instance variables removed.

    In theory, this is possible (and is actually done by other smalltalk systems). The drawback is that the system has to perform a #become: on all existing instances (and derived instances), which may be very slow.
    ST/X may offer this mechanism in a later release as an option.

Notice:

Occasionally, it happens that browsers do not correctly update after such a definition change (i.e. a class definition is changed in one browser, but other browser(s) continue to show the old, obsolete class).
You will notice this when adding new methods, which do not show up in other browsers.
To prevent confusion, it is a good idea to use the "update" menu function of other browsers - or start a new browser if you are in doubt.
This is definitely a bug in ST/X and will be fixed.

Next: Refactorings

[stx logo] Copyright © 2000 eXept Software AG, all rights reserved

<info@exept.de>

Doc $Revision: 1.15 $ $Date: 2012/03/24 19:06:58 $