From: "Stephen Pair" spair@advantive.com
thisContext answer: 1. thisContext answer: 2. ^
I really like this! It gently combines the more general symmetric message sends with the shorthand that's useful 99% of the time.
From: Michael Klein Mklein@nts.net [...somewhat against the idea...] Smalltalk chooses a "fixed" point in language desing space that is good for 99+ % of the time. It also gives you all of the powerfull hooks to handle the remaining small amount. (The powerfull hooks are things like Behavior, #doesNotUnderstand:, #become:, thisContext, etc) These are very powerful for building frameworks that allow "ordinary" (99+%) methods to avail themselves of extreme coolness
Yes, the problem with these sorts of extensions is that the language itself (especially the syntax) has to evolve to allow many of these extremely cool features to actually be used.
There was a good mind-bending paper at OOPSLA a decade or so ago,
on how
to add back-tracking to Smalltalk without VM support (using thisContext).
For example, I typed that in a while ago (posted it to the list as well), and found that for something like it to actually be used, it would need better syntactic support. Asynchronous messaging is a (small) step in that direction, and what I like about Doug's idea is that it tweaks the syntax almost imperceptibly to make asynchronous messaging much more natural to express. If we have to express meta-constructed artifacts in meta-languages (outside the base language), they will not be used.
One of the really neat aspects of Smalltalk for moving language forward is that the fundamental abstractions (object, message, message-send) are actually *much more* general than their current implementations ( data-structures, late-bound procedures, procedure invocation with hierarchically structured name matcing) and need only be tweaked ever so slightly to become even more general.
self doStuff. ^ vs. self doStuff. Processor terminateActive.
I certainly don't want a quiet syntax for killing a process! I want to HEAR the BANG of the bullet that kills it!
This is correct in the context of current Smalltalk-80, where a Process is a heavyweight construct and one most programmers simply do not see. However, when doing asynchronous messaging, "process" termination is roughly analogous to method termination and just about as common. I certainly wouldn't want to write "Processor terminateCurrentMethod" at the end of each method!
I just see the fun of debugging a terminating spurious ^. It's like shooting you self in the foot with a silencer. Your
foot just
disappears without a clue.
I also much rather have single exit methods, with the only exit being termination. Can lead to slightly more complex if-nesting, but is usually worth it.
Marcel