Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110425 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68676 invoked from network); 8 Jun 2020 16:18:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Jun 2020 16:18:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5D7C818054A for ; Mon, 8 Jun 2020 08:02:02 -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=-0.7 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Jun 2020 08:02:01 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BD7575C00EB for ; Mon, 8 Jun 2020 11:02:00 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Mon, 08 Jun 2020 11:02:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=igDbRw TQwnZB5EujZogBOFYHgg8AMAKXb28c3oCm5Ek=; b=XzOPKqkQpivrhfxn1tH/6i 5jYvESk2Am0Ds0i7IT16wf5QKtRwIyPGYwvo8cq2XVx/j9ChjBukLnQ0NlJfVGp+ 1wRhcRT0SCa68DqFtxwHKig5eFt8VqkSBeIgXCZDJJuCnGMOq4APm4WUdfUKPSEv uB4KviLp/Rw7vhINdmP942550BwwfXPB1+UuFnd4v8cEyJoR1iQGcJ8yGyybzmhn arH6hh1mVvz4mwY54rgWStSzGl4ZScX8t0PcaxuF2jzbTWWL9rCBhtYYUvPD6mY1 +9nBh+VBwz1LRVSN5wL8Mq7yAOG2/Ef+rDaYAKce7bPYtuUQq5RXstcwrzAGqIcQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehvddgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdfnrghr rhihucfirghrfhhivghlugdfuceolhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hmqeenucggtffrrghtthgvrhhnpeevheehvdevjeelvdevgfelvefftdejkeelvdekgeeh fffgiedvjefhhfeltdduteenucffohhmrghinhepphhhphdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhi vghlughtvggthhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5B72314200A2; Mon, 8 Jun 2020 11:02:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-ID: In-Reply-To: References: <5ebecd58-9f39-72b9-369d-dbb60b80af36@gmail.com> Date: Mon, 08 Jun 2020 10:01:39 -0500 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax From: larry@garfieldtech.com ("Larry Garfield") On Sun, Jun 7, 2020, at 11:36 PM, Theodore Brown wrote: > > Bracket-based syntaxes, particularly with grouping, are more clearly > > separated from the main code, particularly when used inline. For instance: > > > > `$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var) {};` > > vs > > `$f = <> function(<> int $var) {};` > > To me there doesn't seem to be a big difference in readability between > the function attributes in this example. And with syntax highlighting, > the function keyword itself provides a very clear separation. > > For the parameter attributes, the `@@` syntax example is actually > more readable to my eye. I can't help seeing the `>>` token as a > shift operator at first glance in this context. > > > Finally, typing up those examples, it occurs to me that `@@` is quite a > > "heavy" symbol - it has a large proportion of black (or whatever colour) > > pixels - and inevitably a rather "fussy" one. I find it draws the eye > > more than the angle-brackets do, which feels unfortunate. > > I guess this is somewhat dependent on the font you're using. But in > general I don't think that the symbol being "heavy" is necessarily > a bad thing. It can help attributes stand out better from function > calls, generics, and other nearby syntax. > > Best regards, > Theodore > > [1]: https://wiki.php.net/rfc/attributes_v2#use_cases FWIW, I find both alternatives ugly to my eye. So, there's that. Given that @ is off the table for obvious reasons, my preference would frankly be for Rust's #[], which has the nice side effect of being a normal comment in earlier PHP versions and so attributes can be included as optional without breaking BC. I don't know if that's a big deal or not, but it's a benefit. And it should be no harder on the parser to differentiate than @ vs @@ is. (The only advantage of @@ in my mind is another obvious Star Wars joke.) Something that I don't think has been addressed explicitly in this thread yet is single line vs separate line attributes. Vis: <> class Blah {} vs. <> class Blah {} Syntactically both are legal AFAIK; I don't know which most people will do. The separate line version seems more likely, and cleaner to me, but for parameters people may want to inline it in shorter signatures. Or it may push people to always multi-line those function definitions, for better or worse. (I find that quite ugly myself, but I don't know if I'm in the majority on that view.) My gut feeling is that @@ is notably worse inline. It subjectively feels messier because there's no clear indication of where the end is. On separate lines, @@ and << >> seem about equally ugly to me. --Larry Garfield