Previous | Table of Contents | Next |
The current versions of Smalltalk bear little resemblance to the original implementations. Although the development environment includes some of the same types of code browsers, the environment has turned into a complete team development environment to be envied by most other development environments. The Smalltalk environment runs across almost every platform and provides easy, if not immediate, portability between these platforms. Smalltalk systems also integrate with legacy code and external features easily, regardless of whether these features are written in COBOL, C, C++, assembly, or any other language. Smalltalk can now be packaged as a unit that can be called by other languages, as is done in ObjectStudio version 5.
If the notion of a ubiquitous virtual machine takes off, then a virtual machine will be available on every machine, and that virtual machine could be capable of running both Java and Smalltalk. Smalltalk vendors have created technology to allow some portions of Java code to be generated from Smalltalk programs. Others have created virtual machines that run Java and Smalltalk. Regardless of the approach, the current Java craze enhances the ability of the existing Smalltalk vendors to deliver Smalltalkas well as the subset of Smalltalk technology found in Javato more users on more platforms than ever before.
Smalltalk provides the developer with some unique core functionality. In addition, the Smalltalk library provides built-in features that can be used as they are or extended to suit the needs of the application.
Smalltalk is unlike many languages in that it is compiled to virtual machine byte codes. A virtual machine is a program, usually written in C or assembly language, that provides a primitive set of functions that are translated into actions on the native host platform. A virtual machine is similar to micro-code in construction of computers, and hardware can be created based on the definition of a virtual machine. For example, Java hardware is now being created based on the Java virtual machine.
Smalltalk can be totally platform independent, depending on how many platforms the virtual machine has been localized to support, as well as the generalization of the differing operating system services in the class library. Typically, the GUI, file system, and printing services have been abstracted for all available platforms. Platform-dependent functionality is available but is usually marked as such to prevent platform-specific code from being written by application developers.
A significant feature of Smalltalk for developers is incremental compilation. Because the Smalltalk development tools are tightly integrated with the language and class libraries, Smalltalk code is always written in small pieces, called methods. These methods are edited and saved independently of the entire class, so when a method is saved, it is also compiled into the virtual machine byte codes. Optimizationsincluding in-lining of function calls that return static values or values of variablesare performed at this time as well. Each method save takes less than a second, allowing the application developer to resume his or her work. The methods can even be edited, saved (forcing a recompile), and then executed from within the debugger of an active application.
One of the most elegant features of Smalltalk is that, by definition, everything in it is an object. This includes the classes (which are instances of Class) and MetaClass, if present. Some versions of Smalltalk make special consideration in internal storage for certain data types, such as Strings, Symbols, and Integers, and store them in a different internal format for performance reasons. However, inside Smalltalk, these data types appear as objects because the storage method is encapsulated and therefore is hidden from the application developer.
Smalltalk is a dynamically bound language, which means that the exact execution path of the program is not known at compile time. One favorite practice (which has its pros and cons) is to respond to messages that are not defined for a class by overriding the doesNotUnderstand: aMessage method. This method is sent to any object in Smalltalk if the virtual machine is unable to find an appropriate method for a message. In this method, many tricks can be played, including changing the receiver of the message (anotherObject perform: aMessage), changing the message into one that is understood (self perform: (aMessage selector: #aDefinedSelector; yourself)), or accessing a variable or external feature (self oleInterface performActionFor: (aMessage selector)). Anything that can be done in code can also be done to change the receiver, the form of the message, or any of the arguments, including the number of arguments.
Garbage collection has freed the Smalltalk developer from worrying about the allocation and deallocation of memory resources. Through the magic of the virtual machine, all requests for storage space are tracked, and when an object is no longer referenced by any other object in Smalltalk, it is deallocated and the memory returns to the application to be used again. A significant performance problem can occur if the Smalltalk developer inadvertently creates large amounts of garbage through inefficient coding. When this happens, the allocation and deallocation of memory (garbage collection) consumes a significant portion of the execution time of the program and leads to poor response. Thus, the programmer must still be aware of the creation of garbage and reduce the consumption. One favorite technique often seen when iterating through a set of values is recyclingwhen an object is created, it is reused and then discarded at the end.
The garbage collection algorithms are different from one implementation to the next, but all offer some level of control that can improve application performance. The frequency with which garbage collection is executed, as well as the capability to manually force garbage collection, is available to the application developer. Most implementations also allow the developer to control the memory size of the new space for newly created objects, the memory size of the old space for objects that have been tenured, and the quantity of time required to achieve tenure.
Previous | Table of Contents | Next |