[ENH] Empty return expression
Marcel Weiher
marcel at metaobject.com
Thu Sep 30 10:05:23 UTC 1999
> From: "Stephen Pair" <spair at 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 at 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
More information about the Squeak-dev
mailing list
|