Animorphic ST (Strongtalk) released!

Alejandro F. Reimondo aleReimondo at smalltalking.net
Sun Jul 21 23:50:41 UTC 2002


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.




More information about the Squeak-dev mailing list