Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111270 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44888 invoked from network); 30 Jul 2020 17:31:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Jul 2020 17:31:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 28214180532 for ; Thu, 30 Jul 2020 09:27:29 -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-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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, 30 Jul 2020 09:27:27 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id r4so22525820wrx.9 for ; Thu, 30 Jul 2020 09:27:27 -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=RGnW0/UTV5Ck81b8FdRUa17+x2tJpHHAKUp1+l04MIY=; b=UubRzn4QjEfOkn6ht36JT+0tNgNH0einmY3scMsNsIfTpSmnovgLHdY4lBHjhyVwa9 Q/FSgUlAfDnFqY7bBy/zMgMy6VFNKlJqgJpw87mmf8GAjyd/+doqyNYmek5woG9zUpSi ONsae685vvKWpduTejUypSMTmtTjFYFmIYea2kPGoVG0uaNplvGn9BwC5Lj/8TYfzGjx uIVcZIauuoi3CYkOvEvcvblyE+vU1tfSqnU48Cc3s03Sj/ypDH/3DeWROcXuegujKbuT JT20s9Ew4h4b4MAh1kW6Fet7SSxh/bmiuuFStcZfO4VI2sk54TKZr2eFE+KAUdIFthsE LRLw== 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=RGnW0/UTV5Ck81b8FdRUa17+x2tJpHHAKUp1+l04MIY=; b=XskzY89LtkcUwS0JA6WMO+4EmfPV8UkDTpcSp6qyA4L7O3WdIE80gfA2X8oweFvM2o fChzsZ4KOyVf84U5oqwbAu2Y+igUA9KRolBdbHoxx7zzbumENHUmveMC8ClMRoJiTzui V/CJDOt5j10xQO9Sl3STf+ab3jE1owlTFXDbE6KfPqa0au7AXGAjiVWgQsjnGDQPptPF 8QbMKYwlL/73U5Lvf6rkD5a/zMg3V4MOqneFAVzIkSSkN3SGqGY72mhCayPcN5fs6p2Z NLBRW5rLvJTxSVvWMm20msAxYb/i4VQ+Wd6D/T5O+2fkDU0vbIm3ljsqIruB4zHgRguS e32g== X-Gm-Message-State: AOAM531P23q12BpMV87XJtXxdUwRWwPpQnTqaGttUoLpX4X7wrY0b1nk VdkjBHU2+V10bKQ/jqo4riVccSJMjG2gXgp9oNBl2w== X-Google-Smtp-Source: ABdhPJxHeyPyHIKqFlvzGpmcYGyOwPiEpG42kdFUpvA12K6aitI54g4T6GSBpBPbrIOt+4iGGqyIy+vQUjCIWHdNwVQ= X-Received: by 2002:adf:edd0:: with SMTP id v16mr38253043wro.271.1596126445824; Thu, 30 Jul 2020 09:27:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 30 Jul 2020 18:27:14 +0200 Message-ID: To: "guilhermeblanco@gmail.com" Cc: Rowan Tommins , PHP Developers Mailing List Content-Type: multipart/alternative; boundary="000000000000d2036d05abab25ae" Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000d2036d05abab25ae Content-Type: text/plain; charset="UTF-8" On Thu, Jul 30, 2020 at 6:19 PM guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Question: The key factor of not using @ is due to conflict of > suppression symbol. > While we are in a major (where BC breaks are not encourage, but > tolerable), have we considered the possibility of BC breaking > suppression symbol (@ would become @@) and using @ for Attributes? > no chance, it needs at lesat 1 major release of deprecation before a syntax should be reusable for something else. > > I bet a search/replace wouldn't be that hard to be achieved, and it > would function even today (as @@ is acceptable). Basically, it's a BC > break where code needs to be changed, but backwards compatible as new > suppressor symbol is backwards compatible with previous versions of > PHP. > > Just some food for thought.... > > On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins > wrote: > > > > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson wrote: > > > > > ... I'm still here wanting us to talk about the > > > impact of @@ on static analysis tools. Apparently, internals doesn't > care > > > about these projects. > > > > > > > > > I don't think that's a reasonable summary of this thread at all. I've > seen > > three main types of response: > > > > 1) "I haven't followed the discussion about PHPCS, please could you > > summarise the problem." > > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x > > syntax." > > 3) "I think #[] will cause as many problems for such tools as @@, just in > > different places." > > > > Maybe they weren't always as polite or succinct as that, but not agreeing > > with you is not the same as not caring. > > > > > > As far as I can make out, attributes that appear entirely on a single > line > > with no other text are trivial to ignore in any parser whatever the > syntax. > > That trivial case is slightly more trivial with #[] because a PHP 7 > parser > > will treat it as a line comment; but add a rule to your parser to also > > treat "@@" as a line comment, and you're done. > > > > The problems come when you have a) an attribute definition spanning > > multiple lines, and/or b) an attribute definition inline with other code. > > As soon as you have that, you have no choice but to parse the code > entirely > > according to the grammar of PHP 8, not as "PHP 7 with some warts". > > > > If detecting the end of annotation tokens is really that difficult, would > > it suffice to make the () mandatory (i.e. @@Deprecated() rather than > > @@Deprecated)? The rules for what could appear between @@ and ( are > pretty > > simple, and finding the correct ending ) should be pretty much the same > > effort as finding the correct ending ], since both can occur in matching > > pairs inside the argument list. > > > > Regards, > > -- > > Rowan Tommins > > [IMSoP] > > > > -- > Guilherme Blanco > SVP Technology at Statflo Inc. > Mobile: +1 647 232 5599 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000d2036d05abab25ae--