Behavior messages
The messages described in this section provide access to the properties and attributes of a class, including the methods it defines. Behavior messages are mainly intended to support browsing by allowing developers to perform queries over class structures.
Class queries
allSubclasses, allSuperclasses, includesBehavior:, inheritsFrom:, name, subclasses, superclass, symbol, whichClassIncludesSelector:, withAllSubclasses, withAllSuperclasses
Note:
The Blue Book defines all of these messages except includesBehavior:, symbol, and withAllSuperclasses. We added includesBehavior: to aid in porting, symbol to provide a platform-independent message that returned a symbol equal to the class name, and withAllSuperclasses because it is the obvious complement of withAllSubclasses.
Porting tip:
Smalltalk/V does not support whichClassIncludesSelector:, and it returns a string when name is sent. Objectworks\Smalltalk returns a symbol when name is sent, and does not support symbol.
Tip:
If name is sent to a class, a Symbol is answered. If name is sent to a metaclass, a String is answered.
Compiling
compiler
Note:
This message returns the compiler that is appropriate for a particular class. There might be more than one compiler supported by the system, and each class needs a way to find its own.
Porting tip:
Not supported by Smalltalk/V and Objectworks\Smalltalk, which both provide a similar message called compilerClass. Both Smalltalk/V and Objectworks\Smalltalk provide a set of compilation messages for classes, based loosely on the Blue Book. We have not included such messages in this release, because they intrude on source code management. The usual way to compile methods and add code to the database for developers using VA Smalltalk is to use the facilities provided by the VA Smalltalk development environment browsers.
Creating instances
basicNew, basicNew:
Note:
The standard messages used in Smalltalk to create new instances of classes are new, basicNew, new:, and basicNew:. These messages are defined in Behavior in the Blue Book, but this causes them to be inherited by many classes for which one or more are not appropriate. CLIM and CLDT take a more careful approach. Only the message basicNew is defined for all classes. As specified in the Blue Book, basicNew and basicNew: are intended to be the primitive object creation messages and are not intended to be overridden, because the other instance creation messages are often defined in terms of this one. Other instance creation messages are inherited as specified in the class messages for each CLDT and CLIM class.
Enumeration
allInstancesDo:, allInstancesAndSubinstancesDo:, allMethodsDo:, allSubclassesBreadthFirstDo:, allSubclassesDepthFirstDo:, allSubclassesDo:, allSubinstancesDo:, allSuperclassesDo:, methodsDo:, withAllSubclassesBreadthFirstDo:, withAllSubclassesDepthFirstDo:, withAllSubclassesDo:, withAllSuperclassesDo:
Note:
The Blue Book defines only the messages allSubclassesDo: and allSuperclassesDo:. These messages do not provide any control over the order in which classes are traversed, which is important for some applications. The messages prefixed by with include the receiver class in the classes that are being enumerated.
Porting tip:
None of these messages are supported in Smalltalk/V. Objectworks\Smalltalk supports only allSubclassesDo:.
Instance accessing
allInstances, allInstancesAndSubinstances, allSubinstances, basicAllInstances
Note:
allInstances is a Blue Book message. It is defined in VA Smalltalk to return all live instances of a class. Live instances are those that are being referenced by another (referenced) object, and so will not be reclaimed by the next pass of the garbage collector. (Garbage collection is a Smalltalk process for periodically identifying unreferenced objects and deallocating their memory.) Sending allInstances usually forces a garbage collection to ensure that only live instances are returned. The message basicAllInstances is not in the Blue Book, but experience indicates it is necessary. It is generally faster because it does not require the garbage collection; however, all of the returned instances are not guaranteed to exist.
Porting tip:
Neither Smalltalk/V nor Objectworks\Smalltalk supports basicAllInstances, although Smalltalk/V does have a message with similar semantics called allInstancesPrim. Smalltalk/V supports allInstances. Objectworks\Smalltalk also has a message named allInstances, but it has the semantics of basicAllInstances.
Instance structure testing
instSize, isBits, isBytes, isFixed, isPointers, isVariable
Note:
These messages are all defined in the Blue Book.
Porting tip:
Objectworks\Smalltalk does not support isBytes.
Method accessing
allSelectors, compiledMethodAt:, compiledMethodAt:ifAbsent:, methodDictionary, selectors, sourceCodeAt:, sourceCodeAt:ifAbsent:
Note:
The messages allSelectors, compiledMethodAt:, selectors, and sourceCodeAt: are defined in the Blue Book. Note that methodDictionary has been carefully defined so it does not imply that a real method dictionary is used to store methods. Requiring an actual method dictionary seems to be an unreasonable restriction on implementors. For the same reason we have omitted the Blue Book message methodDictionary:.
Porting tip:
Smalltalk/V supports only compiledMethodAt:, selectors, and sourceCodeAt:. Smalltalk/V uses multiple method dictionaries and defines the messages methodDictionaries and methodDictionaries: to support them. Objectworks\Smalltalk supports all messages except the accessors >>, sourceCodeAt:ifAbsent:, and methodDictionary, although it does support the corresponding set method methodDictionary:, following the Blue Book in this practice.
Method adding and deleting
addCompiledMethod:, deleteAllSelectors:, deleteSelector:, deleteSelector:ifAbsent:
Note:
The Blue Book messages addSelector:withMethod: and removeSelector: are integrated with source code management systems on most platforms. Changing the semantics of these messages to remove this dependency would have broken too much existing code. We decided instead to add new messages that are neutral regarding source code management; that is, they are intended to exist outside the source code management system.
Porting tip:
Neither Smalltalk/V nor Objectworks\Smalltalk supports these messages.
Tip:
Using addCompiledMethod:, deleteAllSelectors:, deleteSelector:, or deleteSelector:ifAbsent: might make the image inconsistent with the source code management system. These methods should only be sent by experienced developers who are certain of the outcome. Objectworks\Smalltalk support these messages.
Method queries
allMethodsNamed:, allMethodsReferencingInstVarName:, allMethodsReferencingLiteral:, allMethodsSending:, allMethodsSendingAll:, canUnderstand:, hasMethods, includesSelector:, whichMethodsReferenceInstVarName:, whichMethodsReferenceLiteral:, whichMethodsSend:, whichMethodsSendAll:, whichMethodsReferenceInstVarName:, whichMethodsReferenceLiteral:, whichMethodsSend:, whichMethodsSendAll:
Note:
The Blue Book only defines the messages canUnderstand:, hasMethods, and includesSelector:. We decided to provide a richer set of method query messages so that it would be possible to hide implementation details without losing functionality.
Porting tip:
Smalltalk/V only supports canUnderstand: and includesSelector:, as well as several messages designed to query methods about instance and class variable references. Objectworks\Smalltalk supports only the Blue Book messages canUnderstand:, hasMethods, and includesSelector:.