Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51883 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1312 invoked from network); 14 Apr 2011 08:59:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Apr 2011 08:59:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=eloybote@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=eloybote@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: eloybote@gmail.com X-Host-Fingerprint: 209.85.212.173 mail-px0-f173.google.com Received: from [209.85.212.173] ([209.85.212.173:56539] helo=mail-px0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/99-44901-087B6AD4 for ; Thu, 14 Apr 2011 04:59:46 -0400 Received: by pxi16 with SMTP id 16so765371pxi.18 for ; Thu, 14 Apr 2011 01:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ck6K269e2OwhAp8EIGt0PpEQ33+jS6TVnEsya1pECck=; b=m/XG1Zwjk7iknm4dpEaTb9voDFUPhi07jHN8jYbX5pc1a7KciTg0PVlUsIQ2PanDQg DXHbkHfJFK9kf3DxUO7Np9y6rR5kmYsIi925sXt0eFjBdV5cYmFD0OOwAyXE/0OOuwLQ 9BNnLFwE3mpoSm3C7asfxUgZqcpFYyZBS+OKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w++f5oTATU4gSt+/w9HuagBfSD37qjQG9b8pCVrcaEpnGQBYUBoOaI+P3NrsbPLfC1 kvzIvBWM4VuQhNOr580sRyT/eJyPe7RMcrhfqKFlkUwqE1B96hzVg8sPBec8b6MBdP+4 yzija2za3OVjxm91Z4kqhldFz888HLdNqurac= MIME-Version: 1.0 Received: by 10.142.186.13 with SMTP id j13mr197171wff.25.1302771582247; Thu, 14 Apr 2011 01:59:42 -0700 (PDT) Received: by 10.142.234.12 with HTTP; Thu, 14 Apr 2011 01:59:41 -0700 (PDT) In-Reply-To: References: <4D950434.3060704@yahoo.com.au> <4D9E0543.1080600@lerdorf.com> <69.82.36433.EC33E9D4@pb1.pair.com> <4D9E34C4.5000406@lerdorf.com> <4D9E429B.20503@sugarcrm.com> <4D9E96B6.6060401@lerdorf.com> <718216446.20110408143441@cypressintegrated.com> <4DA0E71C.9030008@gmail.com> <4DA63ED8.4080402@yahoo.com.au> Date: Thu, 14 Apr 2011 10:59:41 +0200 Message-ID: To: Ole Markus With Cc: "internals@lists.php.net" , Ben Schmidt Content-Type: multipart/alternative; boundary=000e0cd215e26227d904a0dd259b Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator From: eloybote@gmail.com (Eloy Bote Falcon) --000e0cd215e26227d904a0dd259b Content-Type: text/plain; charset=ISO-8859-1 What is the purpose of that generateHash function? It doesn't work in the isset check. Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z]) without notices at all unless any of $x $y or $z are not defined, you don't need to check the indexes one by one. 2011/4/14 Ole Markus With > On Thu, 14 Apr 2011 02:24:56 +0200, Ben Schmidt < > mail_ben_schmidt@yahoo.com.au> wrote: > > I think these shortcuts could be really useful for array elements, but >>> for other variables I am really sceptical and I think they would do >>> more harm than good. Generally I do not really see any reason why a >>> variable should not be 'instanciated' before use. >>> >>> So >>> +1 if this shortcut is implemented to only work for array elements. >>> -1 for any other variable type. >>> >> >> There are two issues here. >> >> 1. Suppression of notice. I agree, it is best done only for array >> keys. It's not hard to initialise a variable with $var=null at the >> beginning of a code block to avoid such a notice, and that is the >> appropriate way to do it for variables. >> >> 2. Offering a shortcut for the common idiom isset($x) ? $x : $y in >> line with the DRY design principle. A notice would never be emitted >> here in any case. The problem is that this idiom is still in wide use >> despite the shortcut ternary operator already provided, because an >> isset() check is different to a boolean cast. >> >> Some thoughts: >> >> - The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's >> not about suppressing notices at all, but about offering a default >> value, and the idiom quite probably only uses isset() because it >> predated null in the language. >> >> > I have never felt the need for a shortcut in these cases. It would be > interesting to see some code where this would be practical. > > > - If we view 2. in this way, the two problems are independent, and it >> seems to me it would be best to solve them independently, rather >> than with a single operator. >> >> So, I suggest: >> >> 1. An array lookup mechanism that suppresses the notice for undefined >> keys. It would work the same as regular array index lookups except >> that the notice for undefined keys (and only for undefined keys) >> would not be generated (it would not just be hidden, but would never >> be even generated). >> > > This is what I feel PHP is missing. Particularly when it comes to > multi-dimensional arrays. Because this feature is missing I tend to do > something like > > function generateHash($x, $y, $z) > { > return "$x::$y::$z"; > } > > if (isset($a[generateHash($x, $y, $z)]) { > ... > } > > instead of > > if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) { > ... > > } > > Arguing about syntax is then a second step. However, my views on this >> are: >> >> > I think it best to avoid discussing the actual syntax before agreeing on > what we really need. > > -- > Ole Markus With > Systems Architect - Sportradar AS > Developer - Gentoo Linux > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --000e0cd215e26227d904a0dd259b--