Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110077 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62868 invoked from network); 8 May 2020 02:57:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 May 2020 02:57:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E8BA41804C4 for ; Thu, 7 May 2020 18:32:37 -0700 (PDT) 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,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 ; Thu, 7 May 2020 18:32:37 -0700 (PDT) Received: by mail-qk1-f172.google.com with SMTP id t3so142146qkg.1 for ; Thu, 07 May 2020 18:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aTSddm4mglaziIDrXuQNvbgHPxkjlQKYXqgneoHcO8Q=; b=0AUhpPRHDvASAjTmwjauzFvxMV6iUd5HJ1dxM5NyhTVMlijBHdHIi6O62O43kwrdjj ++bHoke7s6COZivKD8SmTTHGnmy2cQfURmN1sg+7eVN6ShqP+XGXcelYQcekCfIm6Xcj OyRGjuaKwfpdUVFCXlges8q4/x2tORDSjKfY4Clmu+NuPFs1EoMkIACDbDTzlrBG1IXN bnpqWDZ7vpnCjuwX/Ff44pG1bKJYbjotj2t+NRW11ieW/OPb9NRpBubPyogI9yXOXmU+ R+s7GXnSy3L4JBytX8Ezuzodp9iw8fPDcEiasI8MWGVSGbFKaS894SiCGnCtfn4L+SXP 6L/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aTSddm4mglaziIDrXuQNvbgHPxkjlQKYXqgneoHcO8Q=; b=FQdzx5n57yVvhcwSqEZI/v4LRDLySAKUhnOKDhpq90yGkK1UkbBQj2QkijrbkW7e/N +d2liIcvWTGF8LtRH0AR/x6Peoprahxw2Y5UYIYr/lKFsq+TnePYtKF2Kuswblb3HQrD npHYeZCj3YFceJDa1/jUjPJh+AG0ZtNKvvy6NSzZ/gLAfOG+7sGKSz2vDZGpF5FS05E9 otZ132vv1n4RHruvXJHKgTETCdkpexCRmFuOPZtisFR8Pi3wBkg2jW7CTt/Cd/vJLYl7 PGw6mwsvwBlaB5ylUx9iNegdf7MvaZke5HouScYxbH5s1DgS7fXaLqCyxoTMFJenTl7q a9SQ== X-Gm-Message-State: AGi0PuarUrezuy1zVlfM9y83P1SZZjep8RUw2QlWmkubbt8y6ULbu/Sp QCJKxQYeqlMq1yMGGW5SOmL5n8waZdb11A== X-Google-Smtp-Source: APiQypK3ayDGVh0aHx5ObKCb74R4Mlb1rbSkTysAEcSSGO6WeVm90iMHn/3nxdr4yWPwe9Nfcpdu1A== X-Received: by 2002:ae9:e418:: with SMTP id q24mr336920qkc.69.1588901553291; Thu, 07 May 2020 18:32:33 -0700 (PDT) Received: from ?IPv6:2601:c0:c680:5cc0:4da2:5373:968a:2214? ([2601:c0:c680:5cc0:4da2:5373:968a:2214]) by smtp.gmail.com with ESMTPSA id n206sm96145qke.20.2020.05.07.18.32.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 18:32:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Thu, 7 May 2020 21:32:31 -0400 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <1C09C0A9-1DA4-4753-8E5A-A739D52DA0B3@newclarity.net> <54c5f8f0-1526-53df-0912-0b00e0e54bc3@gmail.com> <44B0AB58-2993-403F-B75C-124AB26B6875@newclarity.net> To: Rowan Tommins X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Parameter Blocks (vs. Constructor Property Promotion and Named Parameters) From: mike@newclarity.net (Mike Schinkel) > On May 7, 2020, at 4:47 AM, Rowan Tommins = wrote: > the current parser seems to handle it just fine. Interesting. You are correct on this point. I was going by memory that = we had lots of problems with nested arrays, I should have tested this = one assertion before posting. > I think you're solving a non-existent problem here. True, but that was only one of the several reasons I proposed the = atlernate syntax, if you'll reread my original post you'll see the next = point: 1. The proposal on the table for Named Parameters effectively converts = all parameters names into public aspects of the their function's API. = Some suggested allowing aliases, allowing OUT-OUT, but AFAIK there have = been no suggestion for how to OPT-OUT of named parameters entirely.=20 IOW, with the proposed syntax Named Parameters would infect every = function/method across all of userland PHP code, whether the developer = wants to maintain it as part of their API or not. This would be like = PHP 8.0 making all private variable publicly accessible. This alternate syntax would make Named Parameters OPT-IN allowing = developers to actively CHOOSE them =E2=80=94 or not =E2=80=94 as part of = their public API. The rest were not part of my first email as I was trying to keep it = shorter, but I now see my brevity was not effective as I had hoped, = so... 2. Adding the ability to fully parse all features of properties and = parameters into two different contexts each with their own syntax = variants will add ongoing maintenance burden of core (or at least it = seems apparent that it would.) 3. The alternate block syntax would simplify userland refactoring to = move properties to parameters and back when compared to the RFC for CPP. = Mostly (all?) it would require would be copying and pasting of lines. = The RFC syntax would require at least a minimum amount of refactoring = (semicolons to commas and back.)=20 4. Who knows what syntax contortions will be required for parameters as = we try to apply new language features that affect properties? IOW, the = current RFC is a less safe for future compatibility than the alternate = block syntax. 5. New features for properties will likely take more discussion time to = determine acceptable alternate syntaxes for using inside the parenthesis = and then more time to implement, possibly delaying universally desired = features or even nipping them in the bud. 6. Userland tooling would need to support both syntaxes, requiring more = work for those project's maintainers, probably delay updates, and = certainly requiring more ongoing maintenance. 7. Userland developers will be confused by and have to learn two = slightly different syntaxes for essentially the same (type of) thing. 8. I believe this alternate syntax addresses Michal Bruzuchalski's and = Larry Garfield's concerns, at least partially: https://externals.io/message/109335#109343 https://externals.io/message/109335#110024 9. This alternate syntax would reduce the desugaring required; only the = value assignment would be needed: https://wiki.php.net/rfc/constructor_promotion#desugaring https://externals.io/message/109335#109515 10. Nikita claims there is a "line" to be crossed when property = declarations have their own blocks and would disallow their use with = CPP. And with the RFC's syntax that seems indeed an appropriate = limitation. But with the alternate proposed syntax it would not need to = be a limitation and I would argue that fewer limitations on future = potential would be better. https://externals.io/message/109335#110034 And finally: 11. The current Constructor Property Promotion adds complexity to the = language where there is no analogue elsewhere PHP, and having things "be = like existing PHP" is a frequent argument related to new features on = this list.=20 PHP is primarily a line and block oriented language, and CPP purports to = add Javascript-like complexity into a single statement. Frankly that is = one of the reasons I so dislike programming in Javascript; I find the = smaller distinct line-oriented statements of PHP much easier to reason = about and would think many userland developers would also. The alternate syntax fits in with PHP's existing line- and = block-oriented flavor much better the RFC's syntax. Simplicity (should) = win(s). -Mike