Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111577 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45774 invoked from network); 17 Aug 2020 13:24:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Aug 2020 13:24:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D16BB180511 for ; Mon, 17 Aug 2020 05:25:08 -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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.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 ; Mon, 17 Aug 2020 05:25:08 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id c15so14750672wrs.11 for ; Mon, 17 Aug 2020 05:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5vjTVBhNkGrgYD+jM/4+bjC6/xABy90TioqEMjFtEZI=; b=VijeUh9mPC74pbK1M81e0aGRStfetoErVUkG79KcRl6tMEJVtV3qBSb1kXH7FABAGe 9J3LXyxaqPYi9OmIXxDVRPDUUK7dWoqsA15W38D6/JMN3FhOlgAbUDydRM81yf/Ou1I6 JKg0qbgdQLiwTsZeiDowJTT1Ctsxt+0X5SZtz5v1Twi1ULzunwNUGytD+r6qsbO0dQFD 6dsCeKTgsU3Ip8vJ6P0dQSCV6RT95FgUFfbuz95G/pSntswp4c+agrcPUI/r0wb7FxhH kS3IL9IEEBJ1BHhcngFXgCnuhJ6UuRMHzIMCbGxs/i3Cbifuu5OsqgzMJduHiF0tAyoc IupA== 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=5vjTVBhNkGrgYD+jM/4+bjC6/xABy90TioqEMjFtEZI=; b=kWQbP7FEmEXjxEmrATs7DE5iORMwKuz/wfnOwCU6V09r4cMTLlM3GQ/9sPQzhPQttj dPY44w6f8pXo+XKryOqMrEaBAj3c0+xz6G+GDe1XJUx0a4nJtj6UWxpqMXJmnVlvu0dl 3pNzxe+krib7FwibsQnhZADoKDv5MCckCZvYXIs8suJXMs/z52hfssNpEtG799wRAUrZ CUwaB7bpO+xXxaWTcFbHncO/WaieN3i0acv9YVrHOQ+Vd1zpiYusWUhLD/OLscIzY5SK lZaesuBods4aRwOTuJzQlGshAj6tDSN8odfLCS31yll7HnA/yUnj+Hv6JvftwahF9MM0 L2sg== X-Gm-Message-State: AOAM533zS/pY7GgP/ZmBdds5TszqLcA39cuM7bZZScofrH4PJcInplgK o9tsGTYjOw9ASqi5BO0he7gkGMB+CClFTH/Jl10EY2troOp43g== X-Google-Smtp-Source: ABdhPJxagr4FSYWLij8oSDqJsbh/fQZdzZE82TZt5lHc3cDrSncTZqWi3U13aiACVMAzqCGz2MmAh/WN7dhORFZdbEw= X-Received: by 2002:adf:ce89:: with SMTP id r9mr16251715wrn.116.1597667107466; Mon, 17 Aug 2020 05:25:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 17 Aug 2020 14:24:56 +0200 Message-ID: To: tyson andre Cc: Derick Rethans , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="0000000000006904f405ad11dc42" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: kontakt@beberlei.de (Benjamin Eberlei) --0000000000006904f405ad11dc42 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 4:47 PM tyson andre wrote: > Hi Benjamin, > > > We are looking for further feedback from the community. > > Thanks, the updated RFC looks much better. > Some more feedback on why the edge cases are a concern to me, > and why the lack of an ending delimiter is similar to parsing problems > already faced. > > I'd agree that restarting a two-week discussion period seems excessive, > and a shorter one is fine with me. > Thank you for the feedback, the section on #[] forward compatibility is something I want to improve a bit more today, your feedback helps a lot. > > ---- > > The references section should probably also link to the other 2 RFC > discussion threads > https://externals.io/message/111416 and the RFC discussion thread > https://externals.io/message/111218 > > ---- > > Developers who are new to PHP (e.g. learning by example) or those who > spend most of their time programming in other languages such as Rust or > Java or Golang > might forget/not know that `#` is a supported line comment syntax, or that > attributes were introduced in 8.0 (not an earlier release). > They might see that code using these edge cases passes syntax checks in > PHP 7.4 and 8.0, and assume it'd work the same way in both versions, > leading to published code incorrectly marked as compatible with PHP 7.4. > > - PHP doesn't warn about calling a user-defined function too many > parameters, making this harder to detect. > > ---- > > The `#[]` syntax makes it possible and convenient to use attributes syntax, > but causes various problems for end users of code using attributes syntax. > I'd expect the drawbacks of bugs caused by edge cases such > as those in > https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_of_forwards_compatibility_procons > to outweigh the benefits of being able to release attributes immediately. > > Putting attributes on the same line as parameters or closures or anonymous > classes seems natural to do to me, > and I'd expect releases would do it eventually, whether it be immediately > in 8.0, years from now, etc. > > Suppose that package `A/A` supports PHP `7.4|^8.0`. > It depends on a package `B/B` 2.0 which supports PHP 7.4. > `B/B` depends on `C/C` `^4.0|^5.0`, where C/C 4.x supports PHP 7 > and C/C 5.0 drops support for PHP 7. > C/C 5.x uses attribute syntax on the same line as other code, > including several edge cases with one-line attributes that parse > differently in php 7.0. > > ``` > public function doDbMaintenance( > #[MyUnused] bool $log = false, // unused in db backend > bool $doPotentiallyDestructiveUpdate = false, > mixed $extraFlags = null, > ) {...} > > // B/B calls doDbMaintenance($log = true) > ``` > > Then suppose that a maintainer or third-party packager (e.g. for a Linux > distro) of `A/A` > runs composer install with PHP 8.0 before building a package such as a > phar, rpm, or tarball > (or `vendor/` checked into git) from `A/A` 1.0. > They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was > buggy > but did not emit any parse, compilation, or runtime warnings if end users > ran that release with php 7.4. > > Then the maintainers of `A/A` and `C/C` 5.0 would get bug reports for PHP > 7.4 for mysterious behaviors with no warnings, > which would be hard to reproduce and debug, despite all involved packages > correctly specifying their dependencies. > End users would also be inconvenienced by bugs that had no obvious > indication or subtler symptoms that may take a long time to get reported. > > This could be worked around by > > 1. Setting `{"config": {"platform": {"php": "7.4.9"}}}` in composer.json > of A/A, > or by documenting that `composer install` should always be run with PHP > 7.4, > but I wouldn't expect new composer users to be aware of the ability to > do that > until they run into issues, and that doesn't help if A/A is a > dependency of another package. > > 2. C/C 5.0 could exit() when bootstrapping when it's run in php 7, > but that seems excessive and not currently done by libraries in my > experience. > > ---- > > If a developer needs to backport code or patches for php 8.0+ to php 7.4 > or older > (e.g. to support legacy applications or OSes that make updating php > impractical), > the lack of a syntax error would make this backporting error prone > if the developer didn't remember this incompatibility > or learn about tools created to catch issues. > (or didn't know about *up-to-date, bug-free* tools to downgrade php syntax) > > ---- > > For > https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanning_for_end_of_attribute_declaration > I'd agree that the lack of an ending delimiter makes token-based > extraction more complicated but still practical, > but it is a complexity that projects such as phpcs **would already face in > similar syntaxes.** > The problems with whitespace and comments and doc comments between tokens > can be fixed by filtering out whitespace and comments before/while looking > to the end of a token. > Projects such as nikic/php-parser or microsoft/tolerant-php-parser would > be what I'd recommend for new code/scripts, > but this is impractical for large existing codebases with third party > plugins such as phpcs. > > A stack-based approach is used for `@[` or `#[`. > A stack-based approach would also be used for `@@Attribute /*comment */ (` > by skipping T_WHITESPACE, T_COMMENT, and T_DOC_COMMENT and ending parsing > of that attribute if the next token isn't `(`. > Skipping whitespace and comments that way already needs to be done to > **correctly** find the end of the function call `myGlobalFunction /* > comment */ (args);` (or `new MyClass /* comment */ (args)`). > For both function calls and attributes, I'd assume style guides would > forbid whitespace and comments before `(`. > > Thanks, > - Tyson --0000000000006904f405ad11dc42--