Anthony Hannan ajh18@cornell.edu wrote:
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:.
That's interetsing, but it seems to make a nuisance of the vast majority of cases, where you are binding a plain-jane variable.
Also, I'm not sure if it's a good idea that what looks like a variable can now have a block sitting behind it. Variables are a fundamental part of understanding how code works, and it would be nice if they behaved according to the expected rules. Computers are already full of rules that are "mostly" true, and everyone has had debugging experiences where 2+2 returned 5 or some other bizarre htings, because they are using rules that are just mostly true. It is nice if I write a variable and immediately read from it, I know I'll get the value back (barring multithreading, which granted is a "mostly" rule itself!).
The blocks approach may make more sense in Self, where people are used to the ambiguity of variables and methods.
In short, I love the implementation idea of tracing the stack to find your context, but I don't like the user-level invocation, either.
-Lex
Lex Spoon wrote:
The blocks approach may make more sense in Self, where people are used to the ambiguity of variables and methods.
This is an interesting observation. In fact, in a Self like system, if designed to allow any kind of object to be a selector (and given some syntactic construct for invoking non-symbolicly keyed slots)...you wouldn't need any additional dictionary like construct. Inserting items would involve using some reflection protocol to install a slot, and messages would be used to access them.
Conversely, dictionaries could be made more intelligent such that associations could either contain a direct value, or some computed value (using a block). And, such blocks could even be made to resemble methods where their receiver context was the dictionary itself. Thus, what you would have is a sort of encapsulated object with named slots. Method invocation could potentially happen when using #at:.
Given this observation, I'd say that there is essentially no difference between direct variable access (using at: and at:put: for example), and access through method invocation; and there would likely not be much difference implementing security in the context of either approach.
- Stephen
squeak-dev@lists.squeakfoundation.org