Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Method Statements
Last updated at 2:49 am UTC on 27 January 2020
Methods are the operations which a class or instance may perform. There is a one to one correspondence between the messages that an object understands and the methods that respond to those messages. The method names represent the pattern of the allowable messages. The operations consist of Smalltalk statements and expressions which are either in the form of messages sent to objects including themselves or messages sent to the Virtual Machine (VM).

One of the major differences is the scope of access to Instance variables
VariablesClass methodInstance method
Class variablesYesYes
Instance variablesNoYes
Global variablesYesYes
Pool variablesYesYes

Syntax

The template provided by the Squeak browser when you may create a method is:

message selector and argument names
"comment stating purpose of message"

| temporary variable names |
statements


The message selector patterns and arguments


message selector and argument names

You may replace this line with the actual message pattern and argument names used later in the statements.

Binary message selectors may be almost any special, non-alphabetic characters but may not end in a hyphen or contain a period (from the Blue Book). (>=, =, ==, @@). It seems that Squeak is much more restrictive in what are valid characters, I could not find a list of what is valid but characters used by Squeak such as period, vertical bar, pound sign (#), caret (^), underscore definitely are not.

Keyword message selectors end in a colon (":"). Multiple keywords and arguments may be strung together, For example, "at: anInteger put: aString"). The selector names concatenated together form the message "name". You will see this as "at:put:" in the browser window.

It is a good practice to name your arguments after the allowed objects (e.g., aString). Since Smalltalk is untyped, if you don't name the arguments after the allowed types or provide clear comments as to which type of objects may be passed, future maintence programmers will be talking about you with bitter disdain (i.e., some times the only way to determine what the valid types are is to search all methods for the use of variables set to the argument value - a very laborious and error prone process).

Another good practice is to recognize and copy the many patterns already in use and duplicate their use for similar functions. For example,
and many, many more. Other programmers will immediately recognize these sequences and understand your code.
This is especially true of the common Smalltalk core objects. For example if the rest of the world has created dozens of conversion keywords for the class String starting with "as" (e.g. asNumber, asHtml, asURL) don't add a keyword of "romanNumber" instead of asRomanNumber.

Method comment


"comment stating purpose of message"

It is a good idea to always have a comment describing what the method does, what it returns, notes about the objects allowed as arguments.

Temporary variables


| temporary variable names |

If any variables are needed just for use while in this method they may be defined here. Use descriptive names beginning with lower case letters so they aren't confused with Global variables.

The actual method statements that perform the operations


statements

Replace statements with Smaltalk expressions. All but the last must end with a period. The caret (^) followed by a value is used to signify return of the value. If an explicit return value is not supplied the system will return the receiver of the message (i.e., the instance or class to which this method belongs)

Example method:
contrivedExample: aString
| dictionary |
dictionary := Dictionary new.
dictionary at: #instanceVar1 put:aString.
^dictionary

Message categories

The Squeak browsers allow you to organize the messages into categories. This is a convenience to help others locate and understand classes with lots of methods. There are several commonly used categories you should try to use if appropriate but you may also make up new categories if you need to.


Method inheritance and override

A subclass will inherit methods from its super classes unless they are overridden.

You may override an existing method by redefining it in a subclass (i.e., create a new method with an identical message selector pattern as appears in a super class). For instance, the method 'isMorph' in Object returns false. Morph is a subclass of Object. Its isMorph method overrides that of its superclass Object by returning true:

Object>>#isMorph
    ^false

Morph>>#isMorph
    ^true

If you don't want to override the complete method, but only wish to extend its statements, you can call the original method using super. See the initialize method in BorderedMorph
BorderedMorph>>#initialize
   super initialize.
   self borderInitialize


Original page contents

Definition
A method describes how an object will perform one of it's operations. A method is made up of a message pattern and a sequence of expressions separated by periods. (Blue Book, p. 48)

Basically, a method represents a named list of statements to be executed.

The method name may define parameters, that is objects to be sent to it, for use inside the method.

It's very important to remember that the method is executed in the receiver's context. That means that in it (and only in it) you can access the objects instance variables and call inherited behavior (via super).

A little about how methods are represented:

A method has lots of responsibilities - it must be very efficient to execute, because that is what Squeak is doing most of the time. It must easy for humans to read and edit, because that's what Squeak users do much of the time. Lastly, it must be represented in a form that is natural and makes it simple to run algorithms like pretty printing (automatic indentation) on it.

All three roles are essential, and the requirements for each conflict with the other two. Since it's impossible to find one or two representations with all properties, Squeak simply uses each of the three and converts between them as needed.

The use that occurs most often is being run by the system, so that has to happen very fast, without taking time for translation. Thus method dictionaries hold CompiledMethods, which are exquisitely tuned to one purpose - run fast.

The form that the users edit, arguably the form that most precisely captures their intentions, is that of text - simple strings. This text from is stored separately from the image in the sources und changes files. Another possibility is to file out pieces of code - a method, a class, the classes in a category or the changeset of a project - in a separate file and use this file as a means of code interchange between developers or users.

It's sad, but all this means that the most natural and precise way to encode the essence of the method, which is its parse tree, simply isn't kept around. It's created when the system parses text (when us users enter new code), or when the system decompiles a CompiledMethod (when the source code is missing), used for whatever purpose, and discarded. Its power and utility are that it's (relatively) very easy to do things with parse trees, including generation of either of the other representations, running metrics that tell you of properties of the code such as it's complexity, or transforming them as in the Refactoring Browser.


The Method Finder is a useful tool for finding methods in the Squeak image.