Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111554 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21487 invoked from network); 16 Aug 2020 10:32:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Aug 2020 10:32:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8224B1804AA for ; Sun, 16 Aug 2020 02:32: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,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-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 ; Sun, 16 Aug 2020 02:32:43 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id r15so2111678wrp.13 for ; Sun, 16 Aug 2020 02:32:43 -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=d4wwcFykQNIe+1tWyTunLZ7qVt2W0GNX1TcKcIcVoLM=; b=KkJQSOD4W/NfMMri4OpH/3MnRMy/xFqgglIjEtJw4PxvEw0jATXfmAu0ixdum9VAde L7HXLQoHGJhboNr0GC8L9qkrUFwoVkG1EwY7to49pLKXho/fhfIIzTz3ruBkgMn5Qx5F S9hPKIXX/3NOkAY/nN+1oWnCsU/QDfH4RH8xKK1d36tMfC4yfXFtTK1tz1ZdjvBVEtSd PQtJh9UlFfrnI/qPJE8nLWqimfzz9jPXQU+sLQkviSlbV62vxlnTcOD45KAzskyW9Jvh 7tf3kcKlJqeOktNDb1FbggtSZnhqnG4XF3fI3PWritHs91yJdTWEf6CTGGTeW07iXg5S OkcQ== 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=d4wwcFykQNIe+1tWyTunLZ7qVt2W0GNX1TcKcIcVoLM=; b=esMEi1bNQi/YER5tygbYzWesIkt0qtTpuq5r+ovGKzVpvg++fURhLDgavfZoHkqypi jD6AHZkgJuX1B5aPV1eRcRL//qkfkhhcMKcRMCNNUaNM+bq/cjRd3umDRF6SLBIKOd6T 5G/bVftObdQbx7JdN3Cguvsk2RO9/3Tuu+sx6Hoa2vVQYheSP4LRnzKVWdEwMwo5MuHl qI7z3u7kZKsapjvO2NUyINSa6nHO6hI5oK8kauMCRejGxg1isPzsP1zlrzfP6rlk9f5N bm7jGdbFB37kS+hww+V5U1R+wT3MWagcujfG4tUSUBbCSa36U51pxAjnA5pZIIHTUGQM 8geA== X-Gm-Message-State: AOAM5337VW/77/TqSVP82GKToAcOuxZeu1Pswqq3QDi9kKfQHr70FCqx MHOcIbSIEZ0k+ELOjhTifzJC/5f/28kIbGzlCWaeaxamI7rZVw== X-Google-Smtp-Source: ABdhPJw1aPGanTE2Q5uxj+bIwtvnIjqOHrnCeZXJqkkue7YdxaPEjmKm8zFOyYAtVFmuf7GdoDGPyeJAKMIxkYRxmKc= X-Received: by 2002:adf:c7ca:: with SMTP id y10mr5145518wrg.255.1597570362130; Sun, 16 Aug 2020 02:32:42 -0700 (PDT) MIME-Version: 1.0 References: <5cc837df-ab47-628a-d29b-46d7933be973@gmx.net> <3A7CECC3-CDEE-4852-BF4B-4EC7CA1BD538@pmjones.io> <7d6c42a4-53cd-5e38-4ffc-02fe490d66a3@gmx.net> In-Reply-To: Date: Sun, 16 Aug 2020 11:32:31 +0200 Message-ID: To: Jakob Givoni Cc: Benjamin Morel , =?UTF-8?B?TWljaGFlbCBWb8WZw63FoWVrIC0gxIxWVVQgRkVM?= , PHP Internals Content-Type: multipart/alternative; boundary="000000000000f05f9205acfb5517" Subject: Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000f05f9205acfb5517 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni wrote: > On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei > wrote: > >> > >> The RFC says 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. > >> However, it's clear that attributes are neither a declaration nor a > >> statement, but metadata about the thing that follows them (unless it's > >> more attributes or comments). > >> The ultimate proof of this is that a semicolon after an attribute is > illegal. > > > > I would like to chime in here since this argument is made over and over > again, even though it overlooks an important point. when we say that > attributes are just metadata, then let's compare them to docblocks with > *are* always enclosed in /** and */ instead of visibility keywords. > > > > This comparison is fair, because doc comments are often multi line and > attributes are as well. When doc comments are single line, they are also > enclosed. > > > > Whereas a comparison with visibility modifiers that are *just* tokens > that *always* are followed by a T_WHITESPACE is apples vs oranges, because > @@ attributes can be followed by a large set of different things: > > > > @@Foo @@Bar // ends due to T_WHITESPACE with " " > > @@Foo // ends due to T_WHITESPACE with "\n" > > @@Foo() // ends due to ) > > @@Foo () // ends with ), the T_WHITESPACE between class and arguments > is valid > > @@Foo@@Bar // ends due to new T_ATTRIBUTE > > @@Foo()@@Bar // ends due to ) > > @@Foo > > ("bar") // ends here in the second line at ) > > function a_function() { > > } > > > > Hi Benjamin, > > I'm sorry, but I don't understand your argument. > It's true that annotations used to be enclosed in a docblock, but that > is not an argument for saying that attributes NEEDS to be enclosed in > a block too. > It's also true that attributes can be followed by many different > things, but still it doesn't follow that block enclosing is NECESSARY. > What I'm saying is that there is still no good argument for why > attribute block syntax is better than non-block syntax. > The only argument that was presented in the original RFC was not > convincing, and I pointed out why. > Nobody says it's ultimately **necessarry** as @@ can work. The argument does not have to be convincing to everyone as we are not making decisions by 100% majority. We are bringing forward a set of arguments why we think end delimiters and enclosing syntax is better and keeps more options open for the future. > I'm also not saying that non-block syntax is better. > Hence, it seems it's just a matter of taste, so far - unless we get to > see some convincing arguments in the rewritten RFC. > > Thanks, > Jakob > --000000000000f05f9205acfb5517--