Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108942 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42381 invoked from network); 10 Mar 2020 13:22:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Mar 2020 13:22:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 52D121804A7 for ; Tue, 10 Mar 2020 04:43:11 -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,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, 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-yw1-f42.google.com (mail-yw1-f42.google.com [209.85.161.42]) (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, 10 Mar 2020 04:43:09 -0700 (PDT) Received: by mail-yw1-f42.google.com with SMTP id j71so13323503ywb.3 for ; Tue, 10 Mar 2020 04:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jbJq9P09frXRZGHzUt/jL6RahGHKzdOQDWhVDWqAx1Q=; b=WFOv1NYiD21fEond6eCBV8vsSx7b0AbziP/4H2dzLwIKjTlfAtMqiMOT+bqT583AJ3 EBq0RJqWStMmpNb5z4GyyHoJ8CBwZQj6v7JtVHcUf8Y3EZoHr4ol+B2XIqdG5DIIt/W8 M0Rzt4EqaWsW6HlOO50cR+ETKUlwghEkTpl49ZQ5BAjvVvDdxFCqy8efFUIBRYe4+4da qK08UvGcdrDyy3MLRShDjbaQ+szcJ+8KH7wUF/HUciwr+/tkf/GqWIHDzeog+Znfzmvu 2iS1Kn6ESeFTFLw+3M3VaB3upIjb2P3OT+0+6QmVq+queeRDG81TDp5ZGo3Z20bo4fEO XBmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jbJq9P09frXRZGHzUt/jL6RahGHKzdOQDWhVDWqAx1Q=; b=UgeoHliA/Tybr6w29l3G32IH5bJuSa0MfeU6KUMehOq7prZIdkgms+OUzmA79H0YCa ByP8C7pJSfb6BXw7azsv2R2W3vZdYYK9q9yMWaiSHdAMA6aXdQyKYPAQTSPOEyejiSBQ 2/CUUC1RzI/0fROeCLjiWhB8hfIbh+V5O7onPPHyaYjQtLhEbGLUlNdwCAqAZCOBjUcy lpctb90xD1olDUPvlgP5mXAO2V7CPA21w6BHFqFZ7zBEcNW0TSgSsa9baVmgHP/y2DGw Tb16HPwQyY2LWDUTRkOQ5FcEMXs69ZfBfPlqol2R3dtxQWaxIVJUeaVcqAv6+lY5xk3r 0OtA== X-Gm-Message-State: ANhLgQ2QKhyQ2PaAP1m0ToyfnArAi0rQqxviB+T2oiM36EZkERHvvjiA nLERRLYxAbMzBed7xin0HSsFug== X-Google-Smtp-Source: ADFU+vvyZhxOiTy+Bg+/7ncUF4vApxc8vB+Tc7bQgyyR9tUSs6suDaqutnZTkGAcA5E/KW0vht7xDw== X-Received: by 2002:a25:f208:: with SMTP id i8mr21883491ybe.219.1583840587680; Tue, 10 Mar 2020 04:43:07 -0700 (PDT) Received: from ?IPv6:2601:c0:c680:5cc0:10a6:890:e364:da48? ([2601:c0:c680:5cc0:10a6:890:e364:da48]) by smtp.gmail.com with ESMTPSA id q11sm14832416ywb.88.2020.03.10.04.43.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 04:43:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Tue, 10 Mar 2020 07:43:05 -0400 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <2227A758-3035-4A43-974C-C4461A096DFB@newclarity.net> To: Rowan Tommins X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Attributes v2 From: mike@newclarity.net (Mike Schinkel) > On Mar 10, 2020, at 6:54 AM, Rowan Tommins = wrote: >> and fear =E2=80=94 have trained many newbies in programming =E2=80=94 = that it will cause >> newbies who see PHP to think it is too complex for them to consider >> learning. >=20 > I think the *concept* of attributes carries a much higher risk of that = than > any particular syntax. The same is true of things like generators, or > traits, which use a more verbose syntax, but take a while to grasp. But if we include attributes, then that point is moot. And orthogonal to = the syntax concern. >> You mention that the good symbols are taken, but why limit ourselves = to >> symbols? Why not use words like PHP uses for other parts of the = language? >=20 > I guess the same question can be asked of any sigils and operators - = why do > we write "$foo->bar($a)" rather than "on foo call $bar with $a"? In = the > end, there's a trade-off: too many symbols become hard to remember, = and > hard to read close together; too many keywords become hard to read at = a > glance, and tedious to write. Easy. Attributes are declarations. $foo->bar($a) is a runtime statement.=20= Developer write at least an order of magnitude more runtime statements = than declarations, so it makes sense that terseness would be a virtue = for runtime statements. The same is not true for declarations. >> Alternately, why not use this (which is probably the best option = IMO)?: >>=20 >> function foo() attributes >> SingleArgument("Hello"), >> Another\SingleArgument("World"), >> \My\Attributes\FewArguments("foo", "bar") {} >>=20 >=20 > This particular example leads to complications with how different = keywords > stack up; would the return statement come before the "attributes" = keyword? How does the return statement affect this example? The return statement = would be inside the braces, the attributes would be before the braces. Are you getting confused because I wrote an empty function body? I did = so because I was mirroring the RFC which used the same convention. > if attributes were allowed on anonymous functions, would they come = before > or after the use () clause? Why would we need to force an order? Let them come in either order.=20 (One of my biggest pet peeves about SQL is that the keywords have a = defined order that you cannot change, and there is no reason they need = to do that anymore with the power of today's computers and parsers.) > The traditional placement above the declaration > line keeps attributes out of the way of the main information about the > function. Yes, and I provided several examples of using keywords that keep = attributes "out of the way of the main information" too. > It's also worth noting that all the other languages referenced in the = RFC > use punctuation, rather than keywords, for their equivalent = functionality: >=20 > C#: [Foo] > Rust: #![Foo] or #[Foo]cont > C++: [[Foo]] > Java: @Foo > ECMAScript (proposed): @Foo > Go: `Foo` or "Foo" > Doctrine et al: /** @Foo */ > Hack: <> @Foo is the only one of those that does not come across as syntax salad. = And [Foo] is not horrible. But as the RFC said, those are not possible. =20= That leaves C++, Rust, and Hack. Not exactly languages that somebody = can master without a ton of development skill. Speaking of consistency, we don't use sigils for named classes. We don't = use sigils for properties. We don't use sigils for traits. We don't use = sigils for interfaces. Why should we use sigils for attributes? Just = because other languages did it that way? That seems like it is just a = bandwagon justification, not a justification based on evaluation of = available options. So I assert again, <> is not a great syntax for userland PHP when = we could use a keyword-based syntax. Point of note, Go does not actually have attributes/annotations. At = best they have the equivalent of structured PHPDoc: https://stackoverflow.com/a/35205657/102699 > That doesn't mean PHP couldn't buck the trend and use a keyword = instead, > but we'd need a strong reason to do so. Clarity? Readability? Ease of learning? Consistency with other = declarations in PHP? Anyway, that's about all I think I'm going to say on this subject. But = if someone else has opinions on the topic, go for it. -Mike=