Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111541 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36030 invoked from network); 15 Aug 2020 21:07:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Aug 2020 21:07:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 001AB1804DA for ; Sat, 15 Aug 2020 13:08:03 -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,HTML_MESSAGE, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-mahalux.mvorisek.com (mail-mahalux.mvorisek.com [77.93.195.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 15 Aug 2020 13:08:02 -0700 (PDT) Received: from c2e9454f9870 (10.228.0.151) by mail-mahalux.mvorisek.com (10.228.0.4) with Microsoft SMTP Server (TLS); Sat, 15 Aug 2020 22:07:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_513e3ee26b2379b3696a0b7445e7a700" Date: Sat, 15 Aug 2020 22:07:57 +0200 To: internals@lists.php.net In-Reply-To: References: <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net> <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io> <7d6c42a4-53cd-5e38-4ffc-02fe490d66a3@gmx.net> Message-ID: X-Mailer: SAP NetWeaver 7.03 Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change From: vorismi3@fel.cvut.cz (=?UTF-8?Q?Michael_Vo=C5=99=C3=AD=C5=A1ek_-_=C4=8CVUT_FEL?=) --=_513e3ee26b2379b3696a0b7445e7a700 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed I am for stopping the current voting too - because the results are very different vs. the previous voting, they are almost random and the discussion is still very hot which violates rule when voting can be started. My personal opinion on the attributes is: - allow not grouped syntax (with @@ or @:), because I think it is much better as code is 2 lines shorter or it is very badly mergeable with conflicts - comments should stay holy, ie. syntax with "#" is not a good choise, program should stay unchanged when ~/\*.*?\*/|(?://|#)[^\r\n]*~s is removed With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 15 Aug 2020 17:36, Peter Bowyer wrote: > On Sat, 15 Aug 2020 at 16:07, tyson andre wrote: > >> I also want a revote. > > I do too. > > Partly because of the rules, but mostly because this discussion has gone on > so long I am now less clear about what is an "ending delimiter" and why it > matters than before. > > And whether the begin/end delimiters are part of each attribute, or used > once for all attributes. For example, > https://wiki.php.net/rfc/shorter_attribute_syntax#lack_of_nested_attributes. > Derek and Benjamin's RFC shows no nested examples. Are nested attributes > even a thing now or did they disappear in an earlier RFC? If they are, they > should be featured. > > On another topic, parentheses and ending delimiters. I have heard Derek's > distinction, but if we're after a syntax with an ending delimiter then I > would propose compulsory parentheses, which means all syntaxes @@, @:, you > name it, would have one. > > If that's unacceptable for solving the "ending delimiter" issue, then > document it in the RFC. It feels there is a lot bound up in the lexing, > either by PHP or by how different people read and understand code. I'm > stabbing in the dark for reasons because it's not been explicit - and it > ought to be. > > This is not a comprehensive RFC, and while I'm ambivalent about syntax > (having swung between <<>>, @@ and #[] over time) I do not appreciate > feeling that it's being bounced through. Room 11 is not this list, and > discussions that happen there (as earlier messages talk about) provide > background and context that is missing when reading this RFC and not having > been part of those discussions. > > P.S. the RFC introduction also states that *"The main concern is that @@ > >> has no ending symbol >> and it's inconsistent with the language that it would be the only >> declaration or statement >> in the whole language that has no ending termination symbol."* >> I had mentioned this in (https://externals.io/message/111312#111335) >> that this statement failed to give concrete examples of problems (e.g. >> parsing ambiguities) >> that the authors believe could be caused in 8.0 or in future releases. >> I'd also stated that I think an attribute is neither a declaration nor a >> statement, >> but that could be resolved by including the definition of >> declaration/statement used by the authors. >> There are various syntaxes in PHP with no ending symbols (`clone`, >> `public`, `yield`). >> (I doubt changing this will make a difference since many people prefer >> `#[]`/`@[]` for other reasons, >> but still consider that sentence to be misleading.) > > Agreed. > > Peter --=_513e3ee26b2379b3696a0b7445e7a700--