Moldable object

Problem

When you code a class, you are several steps away from seeing the consequences of your coding. How can you close the gap between the code and the live objects?

Forces

As a programmer, you want to quickly get feedback about the code you are writing.

Programmers are used to first writing code in a code editor, then compiling and running (or testing) it.

Code editors provide you feedback about the source code, not the live instances.

Solution

Start coding by inspecting moldable object , that is, a live instance of the class you are coding, not in a code editor.

Then you can incrementally add behavior to the object, and create custom views as you code to make the new behavior visible.

Steps

You can inspect a moldable object in many ways.

You can inspect the result of evaluating a Smalltalk expression in a Playground. This can be a code snippet in a Lepiter page, or a Playground associated with another tool, such as an Inspector or Coder.

GtLudoGame new 
  

If you inspect the code above, you will see at the bottom of the inspect a handle to lift and expose yet another playground. (You can also see the handle at the bottom of the next example below.)

You can also click on an Inspect Object button in many tools, for example at the top right of the Inspector of the Ludo Game.

Another way to get an instance is to inspect a runnable method. This can be a unary class-side method, such as FileLocator>>#imageDirectory imageDirectory ^ self origin: #imageDirectory

Another kind of runnable method is an Example method, such as GtMemoryGameExamples>>#chooseMatchingPair chooseMatchingPair <gtExample> | aGame | aGame := self fixedGame. self assert: aGame visibleCards size equals: 16. aGame chooseCard: (aGame availableCards at: 6) . aGame chooseCard: (aGame availableCards at: 11) . self assert: aGame visibleCards size equals: 14. self assert: aGame isOver not. ^ aGame

You can also get to a live instance by navigating to it from another Inspector instance. Click, for example, on one of the cards of the previous example.

If the class you want to work with does not yet exist, you can still inspect a moldable object with the help of a fixit . From the code snippet below, we can inspect an instance of a class MyStackMachine, after clickibg on the wrench icon and selecting the Create class fixit.

sm := MyStackMachine new.
  

Once you have a moldable object, you can incrementally add behavior and custom views, and immediately see the effect on the live instance.

Now you can use the Playground at the bottom of the Inspector to prototype the new behavior. They key point is that the Playground is bound to the environment of the moldable object, so you have access to self and all the slots of the objects. Once you have working code, you can apply an Extract method refactoring, or you can copy-paste the code to a new method.

You can either directly add a new method in the Meta view in the Inspector (see the GtMemoryGame example above), or click on the Browse class button to open an Coder view.

Related patterns

If you are modeling external data, you can create a moldable object from a Viewable data wrapper.

Once you have a moldable object, you can mold it from a Contextual playground.

Known uses

In Smalltalk, it is a common practice to modify code in the debugger, and continue execution. From the debugger one can explore the state and behavior of live objects on the stack, evaluate code snippets to test hypotheses, modify the compiled methods on the stack, and continue running the program.