|The stupid question is the question not asked|
Re: ?: = Obfuscation?by TimToady (Parson)
|on Dec 01, 2006 at 17:42 UTC||Need Help??|
If you want consensus on this one, don't ask more than one language designer. :-)
From a language design point of view, there are certainly some problems with ?:, some of which have been pointed out here. Our approach in Perl 6 has been to try to fix the problems without throwing out the whole idea. One of the problems is simply that it's too hard to see the bits of ?:, so we made the bits bigger. In Perl 6 you use ??!! instead. This also plays into the Perl 6 principle that ? and ! are generally preferred to ask whether things are true or false. There is no natural association between : and the concept of falseness.
But what is the basic idea of ?: anyway? I think it's there to avoid doing extra assignments. You'll notice all the workarounds involve repeating your destination variable, which violates the "don't repeat yourself" principle, aka the DRY principle. So if that's the basic purpose of ?:, and if we teach people that that's the basic purpose of ?:, then people won't be tempted to write things like:
So education is part of it. But the language can do a little more work for you here, and in fact, if in Perl 6 you say
it will give you a syntax error (though pugs doesn't do this correctly yet). What's really going on here is that the Perl 5 compiler is ignoring the precedence of ?: in the middle, as if you had written:
Perl 6 will not supply the implicit parens there, so if you use any operator with a precedence looser than ??!! in the middle, you'll get a missing !! error. This will catch 90% of the bogus uses of the ternary operator, and help teach people that it doesn't mix well with embedded assignment. It doesn't help with a bogus assignment on the right, of course, but usually that error is caught by the fact that most ternary operators do not return a legal lvalue.
Any existing language will give you lots of features in a take-it-or-leave-it way, and Perl 5 is no exception. So it's tempting to try to come up with a simple answer to the question of whether a particular feature is good or evil. Often the answer is "It depends." And when that's the answer, it is often an indication that the feature could benefit from a redesign. When you start thinking about it that way, you start to find you can't just think about the one feature in isolation. You start to think that maybe this applies at all different scales to many of the features in Perl 5, and that the fix for one feature often involves fixing a different feature in parallel. And that's the short answer to why we are working on Perl 6.