Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111234 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21194 invoked from network); 28 Jul 2020 21:02:45 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jul 2020 21:02:45 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D53DA180510 for ; Tue, 28 Jul 2020 12:58:43 -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,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 ; Tue, 28 Jul 2020 12:58:43 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id d17so22513433ljl.3 for ; Tue, 28 Jul 2020 12:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sSkR72WWhgegtPdophWAB+ekn/0aPphpi+7hQC4AOFg=; b=rPPZ7BZDvDcCarjroYz2kpT1BGOe/HXm9qhlokl7Y8/xR8BhieEO+U5GRJ+MkR7nIn f7AWTIR2BbV22MFkmjBRlT83YKxYRKsMljjTqnlnhi7jZojlb5J7D6NAeZ2VaeSvxysR KEc8SSk87IGMHBqC4BM3DsMeKPT0MPlyExDL/LM5DpE063XXCtSH4Dm6uNz+rs8qtrgl zUovRrLRe1G2Rt7cfrWce4ImLeUArJQgvRV8pxj1OAXmbsH6IYmCduIABWk7YlvGIjIv 9W48zqKvPT29NF9QSrhQZ9sGFeIkZhzXLlXGh5BVGLDsk3PcipZr3oJ97v1vM4RjG0OZ 6BLw== 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:content-transfer-encoding; bh=sSkR72WWhgegtPdophWAB+ekn/0aPphpi+7hQC4AOFg=; b=uPzkGyZOlaNwk/LbLjjBCBhiOynvjpYjJoTkbeGXl4LDg2/KKzBn0eWMQspnF8Ithx PPDGxMR69AiPfoBAJrCMuw+k+NB61FTHqgzzz9kvo1wIXjuQNVJTRB/Xe4n6F9At0eL6 h/dF5gAHg58m+4cLdETO00Lif4pX4tcdXL7IeD2HqhgPviP6aP07Nwf/sVGOo481C2pe WrOi/4rBAsnw0BfFpXqAzitI8rO/8Cw8EOgD/RsK78TfIGOjBXSC71i0t5tetuZmlA/5 lEXboDPJx83+Xmx0IGwfJY1glxWZVYZ6Oy3DfLm5Ew9cJHFI0KcKP57LTrj0mG13TRNg OquA== X-Gm-Message-State: AOAM532t0Hork7idsaBrwrcRK0oQg96XYTYaV+pglCpOLtJFG5mYhB6c DAKGo0IXiBsLGoBnghJkYCpH+Ri5418fMO78fOGoIpPz X-Google-Smtp-Source: ABdhPJxTQEVLAMViJY4xmm0uJlwimyXp7ODUBrw21huCdEP7bExR2XMk/SNj2SeRVLAL9OGJCFK5t+XOBByObZVAKMg= X-Received: by 2002:a2e:82cd:: with SMTP id n13mr12763438ljh.162.1595966319444; Tue, 28 Jul 2020 12:58:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 28 Jul 2020 16:58:26 -0300 Message-ID: To: Joe Ferguson Cc: PHP Developers Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change From: marcio.web2@gmail.com (Marcio Almada) Hi, > > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown > wrote: > > > > > Hi Joe, > > > > From the perspective of looks alone I don't care much one way or the > > other between @@ and #[]. However, I don't find the arguments for #[] > > in this RFC very compelling, and it ignores some of the other downsides > > of #[] compared to @@ that should be highlighted. Let's go through the > > arguments from the RFC: > > > > > > Theodore, thanks for your comments, time, and work on the Shorter Attribu= te > Syntax RFC. I appreciate your feedback and I'm also of the mind where I > don't care based on looks alone. The RFC also notes the @@ issues have be= en > resolved by the RFC closing at the end of the month. > > My motivation for this RFC is based on 2 things: > > Firstly, the @@ syntax makes parsing harder (although not impossible) on > CLI tools such as PHPCS. Therefore IMHO internals should make the best > effort to avoid this when possible. > > Secondly, I'd like to see internals use this as a point in the future to > avoid this kind of issue where we need to vote on something yet again > instead of taking the runner up in a ranked-choice vote. Originally this > was my main motivation until I saw the issues raised by the PHPCS users. > Is this issue documented somewhere on github or on any other platform? I'd like to see the discussion and maybe participate in it. Thanks, M=C3=A1rcio