Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109697 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28637 invoked from network); 17 Apr 2020 19:13:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 17 Apr 2020 19:13:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9CBCE180552 for ; Fri, 17 Apr 2020 10:43:57 -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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 ; Fri, 17 Apr 2020 10:43:55 -0700 (PDT) Received: by mail-wm1-f49.google.com with SMTP id g12so3885946wmh.3 for ; Fri, 17 Apr 2020 10:43:55 -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=akR2iahO5P8oYYrc9BhWoTi4GGtHWbGglXitp5rejXE=; b=tidIrweOu4L6lUW8lZ+RMDIAb5TLBRHxKYgtbvtFmXTFgskXu3l2k7JHsh9okKaHzY 33Rl+QtyH6de7n3X85o1s+MK5zPFD0N7098BiIyow4w3Xep+XAD91XhPZXJbzEm17Bvg do1BVDSgEDianPi1bF0r/bxF1dOa/bZ83FoCYzDsH0ncla+En3GK5NcEjJAPJmbOSzqq 19ZPP1tqSSDDmGmRuXXrGvImds4m5QidxG1W1JaQP1i12d6pzpYSgqVnPuFkimm3jhfe jFGeP6N7RrhrInZJd3zzc7+iRezpNaqhs76L3B0olWdk+Liu/Do4ylnDklJ5kpqS0JWl eWXQ== 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=akR2iahO5P8oYYrc9BhWoTi4GGtHWbGglXitp5rejXE=; b=sh5cT+p7RT6WpcQ3x6i4gaRD4xE+DiyhN4s5td3nO/gd+NoxV/DejXDWfoX2KHwEzz CHvqqhv2deg+1JxJbM+50e5kqPsZluICBJllTlgsLOcOo0IreY8PrQoHWwK2vOwq3OgF ThBWaCA8DevqXHQF8wkmAR+wgCTmHaYE0C9DKgx0H5q/JxATsxcjTOScGJFdyzXX45d1 OQck6ahWsVCxR3T5qibT58uNk4nku2EIyhkGwWYBqWJmtj310HG+kXDyC+pE+/WWAjgO x9r1wF2Yo4VtJ53Sm7WDPd8GPg4aPacl7P7w1xkzn6JE0IRDOmzVW2BIFhKf5LSp/qvD CDfw== X-Gm-Message-State: AGi0PubGCoDsF8NGWIxV90XsW/DJBQvIaoC77SUNgj6ji5ZLwg9cKYi2 ggnN7EfS7Wmzb9j7jzpzWtxNbylhRxgO3y8YO9/CCg== X-Google-Smtp-Source: APiQypK+H5fXeLPRH1X7ZTI6hJi5f6WMslnpj+1Ed1Z5BiPJ781KjZ/SFCbtJVXqHzMeJZPZVAXFaqoFKfAQ2H36Sww= X-Received: by 2002:a1c:4946:: with SMTP id w67mr4689746wma.38.1587145431458; Fri, 17 Apr 2020 10:43:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 17 Apr 2020 19:43:40 +0200 Message-ID: To: Theodore Brown Cc: PHP Internals Content-Type: multipart/alternative; boundary="000000000000a6397b05a38017e3" Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2 From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000a6397b05a38017e3 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 17, 2020 at 6:11 PM Theodore Brown wrote: > On Fri, Apr 17, 2020 at 5:49 AM Benjamin Eberlei > wrote: > > > As there has only been minimal new discussion after the last changes to > the > > RFC I wanted to give a heads up that I will open the vote on Monday > > afternoon. > > > > If you have further remarks or questions about the RFC, please let me > know. > > > > On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei > wrote: > > > > > Hi all, > > > > > > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in > > > 2016 with a few changes, incorporating feedback from the mailing list > back > > > then and from talking to previous no voters. > > > > > > The RFC is at https://wiki.php.net/rfc/attributes_v2 > > Hi Benjamin, > > Thanks for working on this RFC. I have a couple questions and > thoughts about the proposed syntax options. > > First, the RFC says that the alternate T_ATTRIBUTE `@:` token has the > downside "that it does not permit whitespace in attribute names to > allow detecting the ending of the declaration." Can you provide an > example of an attribute name containing whitespace that would be allowed > with the shift left/right tokens but not with the attribute token? > This is about whitespaes between token and attribute name, so "@:Foo" is allowed but "@: Foo" is not. Whereas with the hugging As, <> and << Foo >> is allowed. This might come in handy if potentially we allow grouping attributes in the future such that: << Foo("bar", 1+1), Bar("baz", 2+2) >> > The RFC says that "Semantically the attribute declaration should be > read as instantiating a class with the attribute name and passing > arguments to the constructor." But class names can't contain spaces, > so how is it a downside for attribute names to not permit them either? > It seems like it would be a massive footgun to allow attribute names > that *can't* resolve to a class name, since there would be no way to > migrate them to a declared attribute class without a BC break. For this > reason, regardless of the final syntax choice I think whitespace should > not be permitted in attribute names. > This paragraph becomes a non-issue then, the attribute names themselves don't have spaces in them, so they are always valid. > > Secondly, given that attribute arguments are evaluated as constant > expressions, it's far easier for me to read the T_ATTRIBUTE `@:` syntax > at a glance than the syntax reusing shift left/right tokens. With the > latter my eyes tend to confuse shift left/right tokens in a constant > expression with the open/close token of an attribute (especially since > the syntax using bit shift tokens allows multiple attribute declarations > on the same line). > > Consider this example using the shift left/right token syntax: > > ```php > <> 1, 4 << 1)>><> 1, 4 << 1)>> > function foo() {} > ``` > > To me the same thing using the T_ATTRIBUTE syntax is far more readable: > > ```php > @:BitShiftExample(4 >> 1, 4 << 1) > @:OtherAttribute(4 >> 1, 4 << 1) > function foo() {} > ``` > This is a personal assumption here, but I would assume 95% of developers have never used >> or << before or for a long time and maybe 80% don't even know what bit shift means and how it works. I would think nobody needs this in attributes. The syntax is a secondary vote though, so you can just vote your preference :-) > Best regards, > Theodore > --000000000000a6397b05a38017e3--