When working with the Glamorous Toolkit in a context where we are trying to find an answer to a question/problem, we are looking for the shortest path/story/narrative to its "self" by sending messages to that "self" aka question/problem. In case of an answer to this message we have the basis for a possible answer to our original question
we send messages to this self to find out who (object/type) we are dealing with/who we are talking to.
If we do not get an answer, the R in TCR takes effect.
a new programming workflow
What is message passing?
**Note**: Fence after Fence page could benefit from refactoring, since the Messages part is also important to me and ⇒ Lisp – see the transcript of the Alan Kay Turing Award Lecture at tinlizzie by Yoshiki Ohshima starting at 44:47 (at least until 46:30):
> Because the Interesting things to me in the development of OOP and development of practical OOP as it wound up in Xerox PARC was very similar to what happened in Lisp earlier, which is, boy, we've got this incredibly elegant wonderful thing.
45:25 > […] "wow, it's all about messages." The reason it's about messages and not about objects so much is that the messages are the abstractions. We spend far too much time in our field worrying about what the objects are.
self asInspectorModel behavior
> I describe the behavior of my sole instance, nil. nil represents a prior value for variables that have not been initialized, or for results which are meaningless.
"Not a procedure, not a data structure, but a whole computer."
See Message Passing: "until someone passes the block the "`value`" message […]"
However, Smalltalk blocks make it very easy to implement Lazy Evaluation or Normal Order Evaluation semantics (see Smalltalk Blocks Are Thunks In Disguise). Simply pass a block as an argument, and the contents of the block won't be evaluated until someone passes the block the "value" message (or value: or value: value:, etc.) Scheme Language has a similar mechansim with delay and force. (See Explicit Lazy Evaluation)