Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113249 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 5728 invoked from network); 24 Feb 2021 17:01:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Feb 2021 17:01:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D97801804E2 for ; Wed, 24 Feb 2021 08:50:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 24 Feb 2021 08:50:09 -0800 (PST) Received: by mail-ua1-f54.google.com with SMTP id c22so923406uap.10 for ; Wed, 24 Feb 2021 08:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1F9OOn23EO9bkhl8Hh6k7dDbDjCLnyo3/lnwaC8dzGc=; b=tVRb0/yLY+Yig//BwHuf3AV54th6/tMIUiWu0b2rS9Seb61/hANeJWRzUFu5Ks2RMg ieMj278puzXA6Gt2qYMGvRRQOROYgc7+M3N1K7qFlWTsl0dyAtkeZcKwSyH+TbPTZhTM CV62ZkNKFCFEvCY43+RPO+9OdKSgP6x5GW1FSvoF2bphNZZaYZjICyj3IGUiFtRboPT3 6xcfb70go6YhQ176nDt38/pVuJdRJcgiUEoFSIuq8f5XuELGAl1XJ+sp+P+U21p1J0ti h2a8VHd0MsqDu/PJAjNoNq2wNRESyb/kClhDuh9NusxHWf4EbYeNT8FzfpkFxL/Pvnaw eSFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1F9OOn23EO9bkhl8Hh6k7dDbDjCLnyo3/lnwaC8dzGc=; b=NtSq0dnpWQr1lILQO1CrWxfdL9CoIA0lfcjvBh/2ct36Xu0lSeQEA7RC5pKXTZd3KF 2tXAlxVaqq9NDvjq5+ubQvbCDcAKouFdrAnzYRQxqRQ1aDgX+rWYB8Y3yhgEK8SOfpVG FBT2pY+Msj9GVP0I0zzQYIkZ/l1XQpu59t3D/aSCaXpvGlTWbC65PH3dW38VtsYV40S3 y2rj4K7BgYA1tEgxn1WmXhbyRiPAn7refUnT3D6Sx8BqykPttsEYeaBrBvsA8c3zJYXk I3ukgomkz3URqSUi88QMkxllKbxrZtLtibui1aXY+o1aLX3QF8xpoAB7tORZL9wgrbp2 Hqmw== X-Gm-Message-State: AOAM531aBEoF80+Q8fYLu2GpFAxBwQtMA8GZecCG92W0sVLMKg3S/LfN GBfseHW5oMiF4ekQyx6/fKAUjaSYhR+pvrcsLFg9BVsKPqQ= X-Google-Smtp-Source: ABdhPJw/9hlyv0utvLdLwkKwioPh1yYlJ0hj7EajuekGpAJcXSJm6kCI6ATvz5TsR11D8HhBsEh0L8045GDq5ReJkps= X-Received: by 2002:ab0:152f:: with SMTP id o44mr22523354uae.95.1614185408634; Wed, 24 Feb 2021 08:50:08 -0800 (PST) MIME-Version: 1.0 References: <2664e2ef-b965-407c-90fc-77480846a3ad@www.fastmail.com> <84020328-b623-bca1-0c9c-0f7195e08d23@gmail.com> <8CD7D960-51FA-45FE-B88F-2A18BA768DA4@newclarity.net> In-Reply-To: Date: Wed, 24 Feb 2021 11:49:57 -0500 Message-ID: To: Mike Schinkel Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000e2241105bc17d3b0" Subject: Re: [PHP-DEV] Inline conditional that returns null if falsy From: chasepeeler@gmail.com (Chase Peeler) --000000000000e2241105bc17d3b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2021 at 11:35 AM Mike Schinkel wrote: > > On Feb 24, 2021, at 11:27 AM, Chase Peeler wrote: > > On Tue, Feb 23, 2021 at 11:27 PM Mike Schinkel > wrote: > >> > On Feb 23, 2021, at 2:05 PM, Rowan Tommins >> wrote: >> > >> > On 23/02/2021 18:41, Albert Casademont wrote: >> >> Sure, it's not a big deal having to write the ": null" but it doesn't >> add >> >> any value >> > >> > >> > On the contrary, it adds an important piece of information: that the >> default value is "null", rather than "false", or "0", or "new EmptyValue= ()". >> > For instance, it doesn't seem at all obvious to me that this code >> should produce a null: >> > >> > $items =3D []; >> > $itemCount =3D $items ? count($items); >> > >> > I might be more convinced that "null" is the "natural" value if the >> left-hand operand was only checked against null, not "falsiness": in tha= t >> case, you can read it as "if it's null, leave it alone". I'd still be >> inclined towards "too specific to use up more syntax", though. >> >> If you look at it from a software engineering perspective =E2=80=94 whic= h is how >> I assume most on this thread have been looking at it =E2=80=94 being mor= e explicit >> in the code is probably a better practice than saving a few keystrokes. >> >> OTOH, if you view it from the perspective of a *templating* language =E2= =80=94 >> which is what PHP was initially created to be, for the web =E2=80=94 the= n the >> reduction in visual noise from omitting ": null" would be a nice plus. A= nd >> in the case of templating, the distinction between null vs. false vs. "" >> would be completely moot. >> >> > But PHP isn't just a templating language anymore. > > > It is not? If it is not I think a lot of userland PHP developers never > got that decree. > > I didn't say it COULDN'T be used for templating (although even then I'd suggest utilizing a library like smarty or twig) but that it is a lot more than that. I'd also say that, good or bad, the direction of the language in the last 15+ years has been to make it a robust language that can be used for more than just templating. > If PHP currently had support for omitting the third argument on the > ternary operator, then I'd be against changes that required it given the = BC > implications. > > > Can you elaborate on those? > > Well it's pretty obvious. If php currently supported a statement like "$user ? 'online'" then a change that requires the third argument would break every single instance of code that didn't have one and wouldn't provide any functional gains as nothing prevents people from adding on the ": null" if they want to. It's a moot point, though, because PHP doesn't support it. I just included that statement to give context to my views - that I'm not automatically in favor of changes just because they enforce better development practices. > I think just dropping the need for a third argument on the existing > ternary operator is a bad idea. > > I'm ambivalent when it comes to creating a new symbol to support this > behavior (e.g. ?!). I don't really think it's necessary, but, I don't thi= nk > it hurts anything either. > > > >> Repeating code similar to that from the message sent by David Rodrigues >> you can see that eliminating the ": null" is less noisy: >> >>
">...
>>
">...
>> >> Although one ":null" eliminated is not that significant, PHP templates >> for generating HTML are notorious for having conditionals littered >> throughout, with tens if not hundreds of cases per file. So being able = to >> drop the ":null" would be a really nice addition for templating. >> >> To emphasize this feature address templating use-cases one might argue >> that dropping the "or" case of the trinary might only be supported when >> between single-line "" delimiters. >> >> -Mike >> >> P.S. Of course making it work differently between single-line delimiters >> and elsewhere would create inconsistency in the language so I probably >> would not actually argue that, I was just trying to make a rhetorical po= int. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >> > > -- > Chase Peeler > chasepeeler@gmail.com > > > --=20 Chase Peeler chasepeeler@gmail.com --000000000000e2241105bc17d3b0--