ajh18 at cornell.edu
Fri Jan 31 04:46:28 UTC 2003
Hi Allen, thanks for responding, and thanks for the language design
Allen Wirfs-Brock <Allen_Wirfs-Brock at Instantiations.com> wrote:
> The topic at hand is dynamic "variable" scoping.
I prefer messages to variables because they are more powerful and
general. It allows more sophisticated queries, instead of just
returning a fixed value. I guess I'm just proposing another form of
exception handling, where exceptions are distinguished by selector
instead of class, that is why I reused #on:do:.
I even like to think of global variables as messages sent to Smalltalk
or the class's environment/pool. Like Self, no variables just objects
To satisfy your design principles, we could change the syntax to:
Context bind: #world toDo: [myWorld] during: [self bar].
Context would be an object that only understands #bind:toDo:during: and
#doesNotUnderstand:. #doesNotUnderstand: would search the sender chain
for the first #bind:toDo:during: context for the message's selector and
execute its toDo: block. I believe this syntax satisfies the design
principles you mention below.
> 1) It should be easy to explain the feature to a new or relatively
> unsophisticated Squeak programmer.
> 2) A single, specific implementation technique should not be assumed
> or required.
> 3) Usage should not require deep knowledge of low level system
> implementation details.
> 4) Protocol vocabulary should be simple and reflect the intended usage
> 5) Protocol vocabulary should not expose the user to the vocabulary of
> the low level system implementation.
> 6) Protocol vocabulary should not imply or require a particular
> implementation strategy for the feature.
> 7) A distinct feature should use a distinct vocabulary that is
> different from that of other, unrelated features.
> 8) Don't design in "bugs waiting to happen"
> 9) Put the most important things first.
So the real issue is variables versus messages. What do you think?
More information about the Squeak-dev