Hello Diego, [...snip...]
Let's suppose this is the first time with aButton.
I'll write this code: self halt.
Installing a breakpoint can be more convenient (do not change the version of the method). (e.g. install a breakpoint flag in a method or while inspecting an object to break on i.v. access/change) A tracer that log changes while evaluating a chunk in a workspace can be interesting. e.g. you are inspecting an object, write an expression in the inspector an select "traceIt" in the menu (like DoIt but tracing execution) to get a profiling log of messages sent and objects changed during execution... This kind of tools can help to infer the changes done to a system when you send a message (like a "touch and see what happen").
Then I'll open an Inspector for aButton and play with it until I get
enough
knowledge of it.
From the inspector I'll try to change the name, send other objects as names (not only Strings) to get the felling of what can I do this it, etc,
etc.
Play with objects, don't read code.
Yes, YES! we must work on the techniques to work with virtual objects and not with "better" ways of "saying the same". (I consider a good reading on Behavior of Information at http://www.smalltalking.net/Papers/boi/boi.html )
Of course, using a second browser, you can also search a Smalltalk
system,
but that's much more difficult IMHO. You have to interrupt your code writing, change to a second window, remember the type you where looking for, try to find all classes which fulfill that type (a manual step), browse their methods (another manual step), find the method, copy its
name
(yet another manual step) and switch back to the first browser. Alternatively, you can just guess the method name and globally search for implementors, then choose some method for an interesting looking class (you have to remember the class hierarchy and the type->class mapping as the method browser doesn't show) and continue as
above.
That is - IMHO - not as comfortable as a modern IDE (like Eclipse) with code completion is.
No... I don't use any of these options. I use the Debugger and Inspectors to play with objects and this is comfortable to me (and really funny!)
Abstractions can´t be documented entirely, because they must be instantiated in concrete cases (or observed in it´s instantiated form), then always a system documented in source format will be partially undocumented. The best way to learn about a framework is observing the behavior of instantiations in the current context/environment. Will be very welcome a better way to document abstractions (classes, frameworks,...) in concrete/prototypical form, like embedding concrete instances in squeak Books and other active containers. I am using the concept of "Active Model" to get a competitive difference while presenting domain models in image format (See http://www.smalltalking.net/GIM.zip ) the documentation of the model is the system resulting of the exploration of the domain (using Smalltalk as a medium to build "working abstractions"). A Domain model can be understood better in action than in UML or other static format. The details are not important, but the correctness of the model is replaced by it's stability and concreteness.
Let's say you want to rename the method at: in your class to something better and also rename all senders of that method. You're lost in Smalltalk. Too many other classes also implement at: and it's very difficult to guess, which senders call your method and which not. So this refactoring is more a trial-and-error operation than a (how is that called) a semantic-conserting operation.
Yes... It's trial-and-error, what is wrong with this? How did you learn to walk, talk, etc?
If you use a programming language, you can talk to the computer/compiler. You can´t walk, nor touch anObject. ;-) You are in the "computer as a mirror" paradigm (it reflects your "intelligence").
Additionally, while it's a working quite well to test your core business model, it's much more difficult to test your UI.
Testing the UI is an open problem.
The UI is a byproduct of a model; it's a consequence of the model. The refactoring of the UI must be done day by day while building your model and used as a way to TEST the model. The UI objects are the lens to verify your model, then they can´t be wrong (only outdated).
cheers, Ale.