Hi Allen, thanks for responding, and thanks for the language design principles.
Allen Wirfs-Brock Allen_Wirfs-Brock@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 and messages.
To satisfy your design principles, we could change the syntax to:
foo Context bind: #world toDo: [myWorld] during: [self bar].
bar Context world.
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.
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 model. 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?
Cheers, Anthony
squeak-dev@lists.squeakfoundation.org