On Sun, Jul 22, 2012 at 8:12 PM, Alex Aulbach <alex.aulb...@gmail.com>wrote:
> Do we really need that as operator? Why not using new functions for
> special cases.
>
There isn't a need in the sense that such an operator makes things possible
that otherwise aren't possible. There is a need in that there are common
use cases for the ternary operator that are more verbose than they need to
be, and such operators would reduce the cases to their shortest expression.
Rafael's suggestion follows from the principle (which, for lack of a name,
I'd call the Huffman Principle) that (1) common expressions should be
succinct, even at (2) the expense of increasing verbosity for less common
expressions. The suggestion also betrays the BC principle that new versions
of the language should be backwards compatible with others that have the
same major version. Later suggestions are both BC compatible and aim to
improve expressiveness without sacrificing uncommon cases (part 1 of
Huffman without 2, which you could call the Idiom Principle).
One other applicable principle is that common usages appearing across the
breadth of programs in the language should have language or official
library support (core extensions, as opposed to PECL). (Hopefully, my
rendition of this principle is accurate, precise and makes sense.) Note
that common usages that appear only in programs targeting some narrow
subdomain (such as stock trading or medical billing) are excluded from the
principle. Since PHP's domain is web development, anything that commonly
crops up in same is a candidate.
I've yet to identify other competing principles behind some of the
alternative suggestions, but would love to hear some that might help settle
which approach should be implemented (if any).
Don't see much difference between
>
> $a = $b ?: $c;
>
> and (for example I used "i" for "if")
>
> $a = _i($b, $c);
When $b is defined, there isn't much appreciable difference. However, this
behavior already exists, so there isn't much to debate. In the cases under
discussion, a userland function can't suppress undefined variable & index
notices, so it isn't a viable substitution.
PS: Would it be possible to implement functions like ":?()" or "!?()"
> ? Currently this is not allowed by syntax.
This could lead to ambiguity in the grammar:
/* call function ~-, , or "~ ( - 1)"?*/
~-(1);
