Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61668 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65374 invoked from network); 24 Jul 2012 10:25:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jul 2012 10:25:07 -0000 Authentication-Results: pb1.pair.com smtp.mail=ww.galen@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ww.galen@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) X-PHP-List-Original-Sender: ww.galen@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-wg0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:44420] helo=mail-wg0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/5E-17533-3087E005 for ; Tue, 24 Jul 2012 06:25:07 -0400 Received: by wgx1 with SMTP id 1so5251533wgx.11 for ; Tue, 24 Jul 2012 03:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=n9g7oGW1S+DoZnKLJ24AhDrIVnJrdEI03eew+t6MqhA=; b=Hvs9BSlYgUUlXE7b8tBIkw4cl3veCRr29JVIsF84Ns9F8jut9cb9GNRCWxdOXyDKw7 3JiNiv+AJpzLRw8Aqg2IAS5A4v6KoJ/kaiwTrEl76R+ffGAcJs3XkQbBWSFgJ2bA22sT RCHiIwBtdZaf0zz3E2ZJQ7GGfalbDobFdr3S7LwDP0qS4ETqQ7ZyTqf3qHYZuHQoHOdz yxap2OM8bD7IK0vR8MbHbx+JAo4eqgVHXJIsO4SWEslEcX2dRoXmkPUDeSHD48ZqZdxB dEM6xAcQaWKj2PfbPKteQ2pvBgKmIsTWrPR5CAQ7dEdPLrH6pCEG4PDhGCt1jOd99bzk ZLoA== Received: by 10.180.100.133 with SMTP id ey5mr5709128wib.4.1343125504385; Tue, 24 Jul 2012 03:25:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.17.100 with HTTP; Tue, 24 Jul 2012 03:24:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Jul 2012 03:24:24 -0700 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary=f46d0444ee2793e13904c590c68f Subject: Fwd: [PHP-DEV] Implicit isset in ternary operator From: ww.galen@gmail.com (Galen Wright-Watson) --f46d0444ee2793e13904c590c68f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 22, 2012 at 8:12 PM, Alex Aulbach 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); --f46d0444ee2793e13904c590c68f--