Squeak workflow

Question

I'm new to Squeak and Smalltalk but not programming in general(i've some Python experience).

I understand the various tools present in the Squeak environment like the Workspace, System Browser and also the Smalltalk language constructs. I understand how they work in isolation but i'm not sure how they are to be used as a whole.

My question is what is the typical workflow when developing in Squeak. As far as I understand it

I open squeak.
I create a Class in the System Browser.
I then write/test/execute code in the Workspace, adding methods 
to my class based on the code I tried out in the Workspace.
Rinse and repeat for other classes.

Is the above typically what smalltalkers follow or are there things that i've missed. Also other general tips/gotchas(if any) will be appreciated.

Thanks.

BTW, I did search about this and read some tutorials, but did not get any satisfying answers, so no lmgtfy links please ;)

Answer 1

What you describe I would call personal style of development. As there is not a definitive way how you should develop it is hard to say.

But what you describe is viable option. Especially if it isn't clear about how the things really fit together. Smalltalk has the strength that you have all the objects at hand. So it is possible to try it in the workspace. If you get a clue about how it should work it is time to put your code into methods. At the same time it is a good idea to write a test. In the workspace you tested your code with example values. That is exactly a test. As you put the code without the values in a method you could put the usage of that method with the example values into a test. Tests help you to recognize if you change something fundamental while you are constructing the whole thing.

Another style of development I use is using the inspector. Especially if you are fetching things from the net this quite easy to do. Let's say you retrieve a xml from a web api from the net. In the workspace I issue the url fetching command and open an inspector on the result. In the inspector I start to parse the result and on each individual processing step I open another inspector on the result until I have a result I wanted to have. From that point all inspectors are stacked upon each other. You just create methods from every inspector beginning from the last step then close the inspector, take the next inspector and create a method from it, etc.

Finally a lot of developers like to develop with the debugger. You just write code as if it would already exist. You can alter the code while in the debugger and you are able to restart the current execution of the current method. Executing it gets you the next debugger. You add the next needed method and then proceed with the program. You get the next debugger etc.

You see there are plenty of possible styles. But which one is best is your personal opinion.

Answer 2

I usually work with three windows open: two Browsers, and the TestRunner. I write a test to figure out how I want to talk to the object - its API, if you like. Then I run the TestRunner, making sure the test fails for the reasons I expect.

I'll do one of two things then - either write the new method I need directly in the Debugger, and restart the test until it's green, or go to the second Browser and write the method I need.

I'll occasionally use the Workspace, mainly as a kind of scratchpad, like one might use Python's REPL. If you've written a class-side #initialize method, you'll probably want to re-initialise your class from a Workspace.