Re: What should be returned in scalar context?

Truth to tell, my personal opinion is that the entire idea of context in Perl is an interesting experiment in language design that other languages have wisely decided not to borrow...

Im on the other side on this one for sure. Context is one my favorite things in perl. Sure occassionally I get betting by it one way or another, but overall I think its a great thing.

Therefore I am interested in which of the above (or other variations of your choice) people think is a good default behaviour to standardize on..and more importantly why.

Im definately in the don't standardize camp. I would say that part of the artistry of perl is choosing things like this. Its like naming functions. To borrow a chess metaphor, a newbie perl programmer doesnt think about names or context at all. An experienced one deliberates on such things for ages before deciding on the right behaviour, and a grandmaster just picks a name and behaviour and it makes sense. The whole point here is convenience. Does the code read well in its various usages, is the behaviour intuitive and easy to assimilate. Or does it read like gobbleygook and trip you up all the time?

Only experience, and understanding of the usage context (using context at the human level and not perl level) will determine what behaviour is sensible.

I will say however that the whole

return wantarray ? @array : \@ref
[download]

idea doesnt seem like a clean solution. I used to do it a fair bit but I found it trips you up too often. Instead I almost always simply return the reference for things like this. In other scenarios I often make the results vary based on wantarrays status. For instance ive done stuff like this on many an occassion:

sub get_rec {
  my $self=shift;
  print(join ",",@$self),return unless defined wantarray;
  return wantarray ? @$self : join(",",@$self);
}
[download]

Anyway, i would say that context is a bit like a rich cake. A little bit goes a long way, and too much is just awful. But none is even worse. :-)

---
demerphq

_{First they ignore you, then they laugh at you, then they fight you, then you win.

-- Gandhi}

Comment on Re: What should be returned in scalar context? Select or Download Code

Replies are listed 'Best First'.
Re: Re: What should be returned in scalar context? by tilly (Archbishop) on Dec 03, 2003 at 16:39 UTC
We are definitely in different camps when it comes to context. I prefer having my choices be more meaningful. Context has never bought me much that I care about. I cannot count the number of times that I have seen people tripped up by it. And, having done it, I never again want to go through the fun of wrapping code whose behaviour is heavily context-dependent. Adding a million and one precisely defined contexts to Perl 6 will move that from being a PITA to effectively impossible. Arguments about the artistry of Perl I find strangely unmoving. The theory that someone, somewhere, gets it right by habit is all fine and dandy. I daresay that I have more Perl expertise than most, and I sure as heck know that I don't get it right. When I revisit old code, it is a constant complaint. When I visit other people's code, their choices tend to be an irritation for me. YMMV and apparently does. But I'm someone who is bugged by the feeling of solving artificially imposed problems, and I've come to feel that context is one of those. :-( (Of course Perl avoids a lot of artificial problems that I see in other languages. I can live with the occasional misfeature that I dislike...)	[reply]
Re: Re: Re: What should be returned in scalar context? by demerphq (Chancellor) on Dec 04, 2003 at 11:49 UTC
Well, my view on context is that its a wonderul thing that is easily inappropriately used. I'd guess that I use it in less than 10% of the subroutines I write, but when it makes sense I dont hesitate at all. Used sparingly, only when it makes semantic sense, I feel it reduces the chance for errors. As for artistry, I think I may not have been quite as clear as I wanted to. I didnt mean to imply the aristry of Perl, but rather artistry of programming. Designing an intuitive, flexible powerful, extensible interface to a body of code IMO requires an artistic touch. Without the art the interface quickly becomes annoying, frustrating, and counterintuitive. An example for instance is accessors in Perl. Do you do them as lvalue subs (I probably wouldn't), seperate gets and sets ala Java, VB etc? (nope blech), single get/set accessors that return the old value (occasionally but not often) or ones that return $self on set? (my preference.) These are artistic decisions. Theres no science involved. They are all functionally equivelent, but from an aesthetic side (look and feel) they are very different. How many times have you used a crappy API and thought to yourself "this API is soooo clunky", im betting lots just like me. I would argue that the clunky API is the product of an unartistic programmer, and a little bit of art would have improved matters greatly. Anyway, from the artistic point of view you might consider wantarray to be like neon lime green/yellow. Not a lot of paintings would benefit from the color, but its not like you are going to just throw away the tube of paint: one day itll be just the right shade... YMMV and apparently does. But I'm someone who is bugged by the feeling of solving artificially imposed problems, and I've come to feel that context is one of those. :-( To me context is like the invisible argument. If it were to be removed then we would probably end up requiring a flag in the parameters, or worse duplicate subroutines, to do the same thing. I think that this would be worse than the occasional mishap that occurs due to context. So to me its not an artificially imposed problem, its an artifically imposed solution. ;-) This reminds me of a comment I saw once. Some languages totally dispose of pointers (perl references). VB is an example. The argument goes that pointers are a consistent source of error so remove them entirely. The problem then becomes that for nontrivial work you need pointers. So what do you end up doing? Reinventing them. In VB this means using variant arrays and all the horrors that entails. The comment was: "Dont remove features just because they are a source of error, doing so will only require the user to hand code an equivelent, and this is likely to be even worse than the original problem." I would say this applies nicely to context. Removing it would only result in worse problems. At least with context the rules are relatively simple, but more importantly uniform for all subroutines. (I mean rules of how context works, not what a routine returns in a given context.) A rule of thumb for context IMO is that if the effect of context doesnt make sense when the code is read aloud then it shouldnt be provided, but if it would make sense, then it should be. Anyway, as always tilly, a thought provoking thread. --- demerphq _{First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi}	[reply] [d/l]