Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111390 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 17950 invoked from network); 9 Aug 2020 13:14:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Aug 2020 13:14:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 06D091804D1; Sun, 9 Aug 2020 05:13:53 -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=-0.9 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW, 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 mout.gmx.net (mout.gmx.net [212.227.15.19]) (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; Sun, 9 Aug 2020 05:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1596975230; bh=fJoSh/Qmfw086J7T2yZ0zBvPDM41rtChTep0vxW8aGE=; h=X-UI-Sender-Class:Date:To:From:Cc:Subject:References:In-Reply-To; b=hU3k5GOGR3/UkjzwVq+3wSE7xSSJqZvuhDRpFePXw6lszhcxan2tRAEx/31UKidch Qg7OwVpZJdALFGzo2hKAzgHF+xbodTXBDKtVkjQGuDcyNixKqvn3SvU+bmseqN9fm4 Kq70tvZrRkbUzkoVG33S+uqz238uIVY46FhHmOcg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from dedadlershop92.panaxis.li ([212.103.91.56]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtwUw-1ks1yM2VUS-00uJYe; Sun, 09 Aug 2020 14:13:50 +0200 Date: Sun, 9 Aug 2020 14:13:50 +0200 To: Derick Rethans Cc: PHP Developers Mailing List Message-ID: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Provags-ID: V03:K1:j5IYGIytSNODYED665VvArGJDyznUqS3iQ4B4CzMJqgzPkH4u3Q rwIwW+6ruDu+JzbRJynw50XrW5bLWMDnvvOf6xpKpjqHnOlZbVn8z+a7ky0GZTDk+BCjmvi j7iC4LMOOiIU3lCt4izICrnQLYaOTF6CKL8VvqmAuZy2pRliDLt8mCGzJH1zHnvctsq87Fi 65zxaAyTLu13NWdr4mUTA== X-UI-Out-Filterresults: notjunk:1;V03:K0:qKNCpO+Opuo=:qK3EpXq3EqCVHqbOe3lJe1 wews9b/9qB+Iik+19QKEoZtUUCsKQKH7+nQ1xYUxMJDbpVr/P+5zQx+I0ZB8ROpwbKdpoM5Ac NYDmdniXgtJe6E5Al3pRboxNWUrk6Fhc/bDtrJ5ZB74oFLHZpw+ofslbO9Y8V3x0nmrsLnNkn vaCl8KhVXlFSdoTqUupYn21xcrX9ZmAg2OqDEZFKHaBAgAXQx7NjJaEVl3ByE05r5v6jsh4cc hJDbZ9O0YtWb3FC7vQjW1PxBa8TxwgkoiQM9TrMKUsra+CRIaWnQrUU2/Mf4yBe8xuvB5qccI /2xoANSEIeisCkF9PkMtNN8dshhKLs8hWwpo0ojzuiUTt0AVIWsVKdjsRHiNnnUxCAS7Lnc0n dWZpxv56FYPpCe5IViRGaMxeoVl84IrXVtk5KyNk2J6m8BaEFWlftpwb3u3yaMj8okE9ClcpN EITECvW9hmMUlKAjthhhu4Zi3UYzMvIUgs08PmPJ6DuQIsMr+lLoC7qs9bomLd4UyTruoHXH9 rnqMMjls9zdkwUATU8ot7Q4FCBhJ5eE4w/RQjVbsL1rxTqzjv3Ph8/Wtb2f+EOljkwx7Ypdjo ummQ7O5eCdEzqFOxgENiP5dla9xsnRfJGujIRM/3u5YRsEXfe1jD318ASdeg3UnSECi0TEhmr q84gOyU+IxqmOelrksqV2HtYQApu9U5HqszdpH2LZsCDmwtnW/XKnsjAi/ks4hUDc5uSnIJkm PINemgL2FygSrUvTA4sHvXN3S1geHvadgQ0TTcUme5xklyaYri8uGjJ4JRbACesrGGFvlCa6+ SpbJaTEB6pvlx23FQT+C034b6L94MFzvN2LuMWSeW5zTEkibYyaNSX55R4WcTIylSQ2mH33sB 1EZZtVZdPhRDhAXAm7R5/maDi6J0VflV/ktoJrSfRo/1nzDZB1/3TyLkipfn/oPsqjzJgu3d7 gka4Z7QgECtbCu2jwtz76XokfKcjNAY5KwvU6/k77ZU9cTO6QylRqhNDK8t8D6b1OT//D6wgI RGUSYwRN+h1iSMYH1pXBkiLTkk60EInZVraNXrWKR/VZMVguz5I+xwAqGH/TucCmctYVRLv2D ru5B2cmzA85gGh12gG2B7L5H1USlSkzi4S3WOxDSHtZ1vmPQV/Xulw1PMl3R6HOaTFpB1IjJ7 NfpcKyE0MYNyqE1aNutpLkME8aEZX8INVDK8zw7Ojoaj7s39YSgSA9PN4r82SFy2U2X9/Tyr1 KifIRyf0diVtXuG82XVCZPqPjGMjUNdwo7fyRQQ== Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: a.leathley@gmx.net (Andreas Leathley) Hello Derick & Internals, I am a daily user of PHP and read through all the recent discussions about the attribute syntax, and thought I could add some slightly different viewpoints from an "end-user" who uses the current annotations a lot. This is my first time posting, so I am hoping I am doing this the right way ;-) Currently, I am favoring @@, although I don't have strong preferences to other syntax if it is more useful in some way. Why I prefer @@: 1. The @ symbol is hardly used in PHP, except for error suppression and within comments, so searching and scanning over code with @@ works well and does not have much ambiguity. The syntax with [] (and a symbol) is very close to the PHP syntax for arrays and destructuring, and would now have a different meaning in addition to that. This is not the case for C/C++/C# as far as I can tell, as [] is rarely used in those languages so having [] for attributes there makes it quite recognizable/unique. 2. A big argument about the ending delimiter is about consistency. Yet isn't an attribute almost like the "new" keyword, which also only allows a class name and then optionally some arguments passed to the constructor? It is not like you can define anything but a class + arguments as an attribute, and "new" does not have starting and ending delimiters. 3. What would starting and ending delimiters be used for except for grouping attributes? I would be really interested in use cases, and if delimiters are important, then a few real-world examples why they are important and how the syntax will come in handy later would be the best argument for them. After using the current annotations for years it has not occured to me that something is fundamentally missing, and attributes have been used for many years as annotations in PHP as well as in other languages, so there should be some evidence/examples. 4. If at a later time grouping or more options become necessary, something like @@{} could be an optional syntax. Using {} to optionally group something in PHP has a lot of precendence, and if it is only optional, it seems like a reasonable addition while still having the simple just-one-class-with-arguments attributes. When looking at the new RFC, I feel like none of the syntax arguments in the RFC are very self-explanatory or even would be a factor why I would prefer them or not. A larger explanation about each syntax, some real code samples with each syntax (possibly with colors) and longer pro/con arguments would be a lot better for an informed decision, so if there is a lot of contention around the syntax, I think more time to flesh out such an RFC and then do it for 8.1 would be better. At the same time I do feel like @@ would be a good syntax, but if there are open questions or more discussions to be had it might be better to have the time for those compared to having hasty discussions now with a hasty vote where everyone will be unhappy at the end. Best regards, Andreas