Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108718 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 89148 invoked from network); 22 Feb 2020 08:34:20 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Feb 2020 08:34:20 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 361291804D9 for ; Fri, 21 Feb 2020 22:50:53 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f44.google.com (mail-yw1-f44.google.com [209.85.161.44]) (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 ; Fri, 21 Feb 2020 22:50:52 -0800 (PST) Received: by mail-yw1-f44.google.com with SMTP id b81so2638121ywe.9 for ; Fri, 21 Feb 2020 22:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p7bikssnNjDHQGnUYlorqeHTgf4WgJDZG9p2XP34zfY=; b=PE2ZiwC30MqpmX7gCiFEmHtCle3dbMAqRDnV7zVCc/7JTojRG7BCoGMsGijbfTskkW FUECqEaw27aLt/qS8Q7pN52bJb79ezkE4OSG2CJspIdiRefC1vBgl9clroVjPFYqGvV1 HEQ2b/n08IvR2IoJRBP3aHnapHQLFzcAqLfY5srtpBIjmk9P+I5K2fTyiNA1SJwZajqu LHwhfj7EKNmTCSTNlHKRHqfcQG5Z7VSikW32MShdjNVAq2TPcQ1L29p/X2GtoHaUhqTo oMSNt7eEqutxTv6IM5dWW/VrV11dGOZl7QcbyotGJPB7DaSXphr5XbaGNopSRwLhlh8x wbBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p7bikssnNjDHQGnUYlorqeHTgf4WgJDZG9p2XP34zfY=; b=uE5rNtb2bU3ncknz+7bppz2gSLWE1BurDXZErHgAon1JSzcmnH32YkEU4wXETppSGT QRNWKohPtj+/llhmvpv5GCSpi9+yLY9l6HKgnD6RJaXhq6ZiNfm1819RTjJHju8LnDaU nknoIjz1GpupCPzlhIbo42UYCCQUcdMmbDYHpGyYBmQCWwGAa7nqrNGajY6dgMvSvGog ggArTMUfRPS/dswv0Ml+ExwDwLrahx11/2KxDL3eR+WtaZgYvxPWvAbCv60UUowJr7IU 7YT7N+wDBJJOs9PUOmiO/uGdeeAOsyH8hdyPP0UNrFgIrBE7nmyLGuPIRjTqO2EqBHx+ elow== X-Gm-Message-State: APjAAAVjBLh7EviesxN2l3ar0Zd4omaMgWDTlOM4b97SppacKAADyfdu rITaQ62je7+aNWqMJ4u/h6FS6A== X-Google-Smtp-Source: APXvYqxxRxCeMG0A8ThqEu1nN0rLC/Q/QDH5xHs9guX3VwmOOgDGXdwKT/iUTFcurEWFdHZihMFwmA== X-Received: by 2002:a81:6e09:: with SMTP id j9mr30713625ywc.25.1582354248788; Fri, 21 Feb 2020 22:50:48 -0800 (PST) Received: from ?IPv6:2601:c0:c680:5cc0:4032:6b9e:6c2d:f784? ([2601:c0:c680:5cc0:4032:6b9e:6c2d:f784]) by smtp.gmail.com with ESMTPSA id l19sm2450729ywe.29.2020.02.21.22.50.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2020 22:50:47 -0800 (PST) Message-ID: <08159EA6-61E5-4E85-AC43-9637783315EA@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0A4E0A55-D440-4B9A-B733-7EB3B9D03AB4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 22 Feb 2020 01:50:46 -0500 In-Reply-To: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com> Cc: PHP internals To: Rowan Tommins References: <8B2AFC37-9425-440C-B89D-61CBAAB0CDDD@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_0A4E0A55-D440-4B9A-B733-7EB3B9D03AB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 21, 2020, at 5:20 PM, Rowan Tommins = wrote: >=20 > On 20 February 2020 14:13:58 GMT+00:00, Nikita Popov = wrote: >> Hi internals, >>=20 >> I'd like to start the discussion on the "explicit call-site >> pass-by-reference" RFC again: >> https://wiki.php.net/rfc/explicit_send_by_ref >=20 > My instinctive reaction is still one of frustration that the pain of = removing call-site ampersands was in vain, and I will now be asked to = put most of them back in. That is a great example of what is known as a "sunken cost." =20 In summary "A a sunken cost is a cost paid in the past that is no longer = relevant to decisions about the future." > It's also relevant that users already find where & should and should = not be used very confusing. One of the reasons it is confusing is because developers are currently = required to use the ampersand in one place and not the other. Making it = always used removes said confusion as they would no longer be a reason = to have to remember when and when not to use the ampersand anymore. > There is a potential "PR" cost of this change that should be weighed = against the advantages. To say "We fixed something that in hindsight we've since determined was = a problem." How is this a concern? =20 And when has the PHP community primarily worried about PR cost anyway, = except with Hack starting eating PHP's lunch in terms of performance? =20= > I'm also not very keen on internal functions being able to do things = that can't be replicated on userland, and this RFC adds two: additional = behaviour for existing "prefer-ref" arguments, and new "prefer-value" = arguments. I used to have the same preference. And then I realized that languages = that allow everything and do not withhold low-level functionality allows = userland to create of DSL-like extensions that can result in highly = fragile and obtuse architectures. Just look at Ruby. And yes that is an abstraction, but so is a generic concern about adding = internal functions that cannot be leveraged in userland. =20 So what specific problems would having these enhancement cause for the = language? > My current opinion is that I'd rather wait for the details of out and = inout parameters to be worked out, and reap higher gains for the same = cost. For instance, if preg_match could mark $matches as "out", I'd be = more happy to run in a mode where I needed to add a call-site keyword. This sounds like preferring perfect in the (potentially distant) future = vs. much better today. If this feature does not block some abstract vision for a perfect future = and is something that can be delivered in the short term to solve = real-world problems today, why stand in its way? -Mike= --Apple-Mail=_0A4E0A55-D440-4B9A-B733-7EB3B9D03AB4--