Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111367 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 25603 invoked from network); 7 Aug 2020 12:39:46 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Aug 2020 12:39:46 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2A1551804D1 for ; Fri, 7 Aug 2020 04:38:09 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (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, 7 Aug 2020 04:38:08 -0700 (PDT) Received: by mail-io1-f68.google.com with SMTP id l17so1549851iok.7 for ; Fri, 07 Aug 2020 04:38:08 -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; bh=KjQVMj9hE1CfxSyQt+lpkM6yvhEDRi5B/kMQBemFHOE=; b=gdkP6n+W/Slz3NuezSK6MuJEha3yaqOih4JRAjU6lb2kVlzGTzXFoEoRz2kIBh8kZx 6/hnAgm54LVUWFQEz5d3ACSmQz3VkWjySj2zcttxaZhPWEMFIuAN0jzJHyE2vf0zD1Wr MkwY3CfVeCq0cSXZvW9N2TvCFtwmXvV/facVqI9mhJBpAwNFki7qBMYcU4gdTjk/q4Gn n+UJPp7FWRBuqRwkUjPqXqa04BU/e543D3F5Dq3/hyzHbRQKCy1H/zWB4EBVzLNSBm0s ut0SrsBf6vWVs0d1hP09tFxrnYz9iaJ8O7Rm/jHekcgJgt3Vp6zu2R/0TVDx3T6tM+gm MH+w== 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; bh=KjQVMj9hE1CfxSyQt+lpkM6yvhEDRi5B/kMQBemFHOE=; b=FSRnAkGZc4dfQm1Icek5bg5oaYbXq1zeqhgdYsm5HcepA/JqZRINqID1k1kO+qi0DL bVtQktjKGLuo7eCt7d5dFVOZ9Cg3zzbxjc6Bfsu4k0+pbX6cx0AHkYFhY0Xxi1MG0znT sk18xJIXLpDvFAnvy4XCbIw2qk9aw0ypL2TBBcLb2nJLyF6ALaEVVaf78T2poyQjYCSF ixPUKQWPM1xfsmxRXiRX5zJrnFUkoI5diN3ABZdIIWo1X1+h902OvuuTwGinEg+kZNNm 7rei6y2UIQXGvuptan8WwjCOQQgXfdbh6cCM8B4soyHAZvbx+B07wKwFGi8DGISLGr6C QnLA== X-Gm-Message-State: AOAM532cigALd0i2enRCct1pDZZElnl3465X9sIrT6NieD+tfBs07C8H c85aK5VhkYGBx2qIrZSU7/kZlgoiwteAvS/WxcaTQ/2v X-Google-Smtp-Source: ABdhPJxcneSWnVrl+lfZ6Cdxn0IepMCpx26D1zYExFIFQNfTIYG37z+rbGX8+c2zlIlFNlBYz7+c+Ku/NvDvrX1ddgw= X-Received: by 2002:a6b:3bd4:: with SMTP id i203mr3993365ioa.205.1596800283780; Fri, 07 Aug 2020 04:38:03 -0700 (PDT) MIME-Version: 1.0 References: <20200806091749.64675445@mcmic-probook.opensides.be> In-Reply-To: Date: Fri, 7 Aug 2020 12:37:50 +0100 Message-ID: To: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000b12ace05ac480915" Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2 From: rowan.collins@gmail.com (Rowan Tommins) --000000000000b12ace05ac480915 Content-Type: text/plain; charset="UTF-8" On Fri, 7 Aug 2020 at 12:03, Derick Rethans wrote: > > You still haven't addressed any of the deficiencies that the other > alternatives don't have: > https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal > That table would be a lot more useful to steer the discussion if it was accompanied by an explanation of each of the factors, as some of them are extremely vague: * Do the three "Yes"es in the "Difficulties with Userland Parsers" relate to the same problem? What is it specifically, and how does <> avoid it? Is it really true that <> has _no_ difficulties for userland parsers, or just that it avoids that particular problem? * "Number of required characters" is the number for a single, ungrouped attribute. The number of characters saved by grouped attributes would be a more useful measure than just whether they're possible. * There is no explanation of _why_ end delimiters are an important factor. * If it is important, my question before stands as to why "@@Attr()" with mandatory parentheses wouldn't receive a "Yes" in this row. * "Familiar with Docblock Usage" seems to be rather subjective; is it the "@" that makes it familiar? the lack of extra brackets? I'm not sure it's fair to boil this down to a straight yes/no. * "Tokens Used" seems to be an implementation detail, with no explanation of why this would make a difference to anyone's vote. Regards, -- Rowan Tommins [IMSoP] --000000000000b12ace05ac480915--