Delbert Murphy <dmurphy at infratecture.com> wrote:
> I think that Dan's observation is spot on..."if there is no other reason for 
> the tuple", then you can use the multiple arguement block.  But, I contend, 
> just as Juaneta Ewing did (see Steph's mail), that you very rarely use the 
> tuple for just a return value.  I'll wager that the tuple (and other 
> associated responsibilities) belong in a class of it's own.  Then, as I said 
> before, it's just a matter of keeping track of another class...
> 

Somehow the functional languages guys seem to use a *lot* of unnamed
tuples.  I'm not sure why their code is different from OO code.  I have
to say, though, the mental effort of coming up with a name for "this and
that" is a bit of a distraction from the main line of effort.  I have
that issue with Squeak in general: I love being able to name classes,
but I hate *having* to do so before I can play with them.  The scripting
system in Squeak is really neat in that you get a default name (eg,
"unnamed17") for both clasess and methods, and then you can go back and
name it up in a later tidying pass.

Anyway, something else to toss out is that the Common Lisp guys have a
nice multiple-value-return system.  One of the neat things about it is
that if your code only expects one return value, then you get the
*first* return value.  I like this a LOT better than the usual thing of
putting all the values into some sort of holder.  It's nice that you
*can* get your hands on all the values, but that is an unusual behavior
and people should have to be explicit.  It's like touching thisContext
all the time -- ick!

Put another way, it's great if your multiple-values code can be
*explicit* about how many values it expects to get back, and the
interpreter can do a right thing such as picking the first value or
flagging a mismatch error.  If your code really does want to handle all
the multiple values, then it should explicitly call the method in some
specialized way.

I'd love Squeak to have a good multiple-value-return system, and I'd
love to somehow have default names for classes (and more generally to
make class creation lighter).


Lex