|Problems? Is your data what you think it is?|
Re: Re: On Scalar Contextby demerphq (Chancellor)
|on Apr 23, 2004 at 15:49 UTC||Need Help??|
How do we move to get this standardized and rational?
This is standardized and rational. Its just not applying the (incorrect) naive assumption that calling a subroutine in a given context is like working with an array, hash, or list. Its standardized and rational in that most people would consider the behaviour of most of these items to be perfectly natural and DWIM.
Think about it: What use would each() be if it returned 2 (as an array would) or the value (as a list would). Neither of these is particularly DWIM, and would mean that the language was poorly huffman coded in the sense that youd have to write my ($key)=each %hash; instead of my $key=each %hash; and in my experience wanting the keys of a hash is more common than wanting the values.
Work through perl and youll find that all sorts of stuff has been specifically selected to be DWIM and also more or less huffman coded, the more common keywords are short, the less common ones are longer than their more commonly used relatives (my -> our, push/pop -> splice come to mind, im sure there more). On a few occassions Larry has mentioned in his writing being motivated by brevity, at least in part, in his design methodology.
Meanwhile, never make any assumptions about a list function in scalar context -- it's all random :)
Not random, DWIM (hopefully). But yes, never make any assumptions about the relationship between what a function returns in list or scalar context, or for that matter what it will do in void context. Theres no logic to it, beyond what the author thought was the smartest thing at the time. The point is always check the docs, or the source to see what actually does happen.
If you read p5p you'll find numerous large threads debating how subs can have new behaviour provided for contexts where it isnt already well defined. Somebody recently said something like "the problem with defining the new behaviour is that often the ideas proposed are so far from what the people who actually might do the work to implement the feature would expect that they arent interested in doing so." Which is an interesting point in itself.
First they ignore you, then they laugh at you, then they fight you, then you win.