ENVY - The 10 Minute Guide

The ENVY Project Model

ENVY is the code repository for IBM Smalltalk. Most of the tools (browsers) in IBM Smalltalk are ENVY-aware and follow the project model ENVY implements. This project model does not change the normal Smalltalk notion of classes, hierarchies and methods so much as it controls the grouping and loading of the objects used to effect the notion of classes, hierarchies and methods.

The ENVY project model is quite a bit like a layered onion:

Configuration Map (ENVY World View)

Configuration maps contain Applications. Configuration maps may also contain links to other prerequisite configuration maps.

Configuration maps are useful for loading a particular code "configuration" (thus the name) into a Smalltalk image. It is possible to customize links to any prerequite maps (knows as "required maps" in ENVY-speak) such that the links are followed only when certain conditions hold true. This is useful for choosing prerequisite maps depending on the operating system your image is running on. The following config expression, for example, will only hold true for a UNIX system:

(System respondsTo: #subsystemType:) 
    and: [(System subsystemType: 'CFS') = 'POSIX']

If we could draw a picture of a configuration map containing several platform-specific configurations, it might look something like this:

Note that links to required maps are optional. Most of the maps shipped with IBM Smalltalk do not have required map links. Also note that when you load a map with required maps, the required maps load first and the applications load last.

Browser: Configuration Map Browser


Whereas Configuration Maps organize code that is outside of the Smalltalk image, Applications organize code that is inside of the Smalltalk image:

  • Applications are used to maintain - and enforce - prerequiste relationships. AbtCldtAdditions, for example, will not load into an image that does not also contain its prerequisite, AbtPrimitiveBaseApp.

  • Applications control classes. Within a Smalltalk image, each class has one and only one definition, and that definition is owned by one and only one Application. The class definition defines the class shape (instance vars, superclass) as well as its set of pool dictionaries.

  • Applications can also contain extensions to classes. An Application cannot, however, contain both the definition and an extension to the same class. It must be one or the other.

    The Application AbtCldtAdditions, for example, contains an extension to the class Integer. This extension adds methods like #abtAsUInt32 to Integer.

Browser: Applications Browser  ,  Application Manager


Classes are defined in (and controlled by) a single Application. Each class has exactly one definition within the image. It may, however, have any number of class extensions within the image.

Class extension

Class extensions are collections of additional methods for a class.

  • Class extensions do not change the class shape... they only add new methods.

  • Class extensions cannot override a method.

    Any method defined in a class extension must be unique for the class being extended. For example, Point already contains the method #x:, which is owned by the SubApplication CLDT. (CLDT stands for Common Language DataTypes.) If you tried to extend Point by adding a new definition for #x:, the system would not allow it. It would assume that you were, in fact, changing the original definition of #x: within CLDT. You could, however, add a new method, Point>>#myX: because that (probably) does not yet exist within your image.


As we mentioned previously, methods are owned by Applications, not classes.


SubApplications are like nested Applications. They cannot, however, be loaded independent of their parent Application. SubApplications are useful for:

  • Isolating platform-specific code.

    Like Configuration Maps, SubApplication loading can be controlled via Smalltalk configuration expressions.

    Suppose, for example, that you had some code that should only be loaded into the image if the image is running on a Windows machine. In such a case you could put that code into a SubApplication attached to a configuration expression that only answers true when evaluated on a Windows machine.

    (See the Application CommonFileSystem for a good example of this usage.)

  • Grouping code into related concepts. The Kernel application is a good example of this.

Note: It is quite easy to overuse SubApplications. In practice, a flat Application (no SubApplications) is usually quite sufficient... and much easier to maintain over time.

The ENVY Development Cycle

Good ENVY development habits protect you from losing your work in the event that your Smalltalk image is lost or damaged. (After, for example, a sudden power outage.)

When starting a new project...

  1. Create a new Configuration Map for your project. Leave it open. (Do not version it at this time.)

  2. Create a new Application to contain your code. Immediately release this open Application into your project Configuration Map.

  3. Open an Applications Browser on your new application. Start writing classes and methods.

  4. Frequently version and release the classes within your Application. (You do not need to version the Application itself quite yet.)

When resuming work on an existing project...

  1. Start up your Smalltalk image.

  2. Make sure that the image contains up-to-date code: Load the open edition of your Configuration Map.

  3. Continue to write classes and methods, versioning and releasing classes frequently.

When you reach a milestone (Daily, weekly, whenever...) of your choosing, version up your Application and then also version your Configuration Map. This puts a "stake in the ground" that you can always return to. For future work, create a new edition of your Configuration Map as well as your Application. Release your new Application edition into the new open edition of your Configuration Map and you will be ready to work as before.

Your final product will be represented by one of the versions of your Configuration Map (usually the most recent version.)

ENVY Tools

System Transcript

Very Cool Picture of the... System Transcript

Configuration Maps Browser

Very Cool Picture of a... Configuration Maps Browser

Configuration maps are created, modified and loaded using the Configuration Map Browser. To open a Configuration Maps Browser from the System Transcript perform Tools -> Browse Configuration Maps .

Applications Browser

Very Cool Picture of an... Applications Browser

To open an Applications Browser from the System Transcript perform Tools -> Browse Applications .

To create an application, perform Application -> Create -> Application

To create a Class, perform Classes -> Add -> Subclass

Public and Private are solely for the convenience of developers and will not affect the access to methods during execution.

To create a Method, perform Methods -> New Method Template

To categorize methods,

Categories are solely for the convenience of the developers and will not affect the execution of the methods.

Useful menu options available in most browsers



Very Cool Picture of a... Workspace

Workspaces are simple text panes in which you can try out snippets of code. In some ways Workspaces are almost redundant because just about every text pane in every browser allows you swipe and execute Smalltalk code. In a sense, for example, the System Transcript is just a very special Workspace.

Perhaps the single redeeming feature of Workspaces is that you can use them to browse (edit) text files. (This is especially useful if these text files contain snippets of useful code that you can swipe and execute.)

Once you have highlighted (swiped) a bit of Smalltalk code in a Workspace, you can choose to act on it in one of three ways:

  1. Execute it. Execute the code without giving any visual feedback in the Workspace itself.
  2. Display it. Execute the code and then print the resulting expression to the right of the swiped code.
  3. Inspect it. Execute the code and then open an Inspector on the result.


Very Cool Picture of the... Debugger

The Debugger is displayed when an exception is thrown.

The five panes of the debugger are:

  1. Process List: Gives you a list of all of the processes you are debugging.
  2. Message Stack: The messages that were executing when the debugger was opening
  3. Variables: All visible variables including temporary variables defined in the current method.
  4. Variable Values: The current value of the variables that are selected
  5. Description Pane: The code for the method. The expression sent is highlighted.

There are four ways you can step through the code in the stack.

  1. Into: Displays the code and takes you into the method selected.
  2. Over: Executes the message without displaying the method's source.
  3. Return: Execute the rest of the current method up to the return statement.
  4. Resume: Continue the current process until it completes

Useful functions:

There are five ways to get the debugger to come up

  1. From the System Transcript under the Tools Menu
  2. By executing a "self halt". This is most commonly used when you need to stop within a workspace script
  3. An exception is thrown because of a code problem
  4. Clicking on the User Exit Button
  5. A breakpoint is encountered
  6. .


Very Cool Picture of a... Breakpoint


Very Cool Picture of an... Inspector

An inspector is awindow in which one can see and manipulate an object.

Changing the value of an object or its variables
Some useful Inspector menu items:

Application Manager

Application Manager

Untangling our Words

There is an actual IBM Smalltalk class named Application. In the context of this document the word Application will always refer to this IBM Smalltalk class and not the more generic "your program is an application" definition.

Do not confuse the ENVY concept of extension with the Java subclassing keyword, extends . The ENVY concept of extension is one of adding new methods to a class without changing the original class or its methods. From an ownership perspective, ENVY looks at both the original set of methods and the new set of extension methods as separate, shrink-wrapped entities. The new extension methods are effectively grafted onto the side of the class as peers with the original methods. Once "grafted on" they act, from the programmers point of view, as if they has always been part of the original class definition.

A number of IDEs use the term project in a somewhat formal sense to describe the complete set of files and objects needs to develop a program. In this document, the term project is merely used in the generic sense. There is no ENVY object called, Project.