Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108939
MIME-Version: 1.0
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <2227A758-3035-4A43-974C-C4461A096DFB@newclarity.net>
In-Reply-To: <2227A758-3035-4A43-974C-C4461A096DFB@newclarity.net>
Date: Tue, 10 Mar 2020 10:54:59 +0000
Message-ID: <CALKiJKqD=rZLN9r999byR=bDVhjiKLJ1ODKqZbwmfY9AojooSg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002449c105a07df45b"
Subject: Re: [PHP-DEV] [RFC] Attributes v2
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000002449c105a07df45b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 10 Mar 2020 at 01:02, Mike Schinkel <mike@newclarity.net> wrote:

>
> I find angle brackets extremely hard to read
>


You're definitely not alone in disliking the syntax, but I think it
actually looks quite neat. It reminds me firstly of templating languages
which use {{foo}} for placeholders and/or keywords, and secondly of French
quote marks, =C2=ABguillemets=C2=BB. It looks ugly in e-mails using variabl=
e-width
fonts, but that's not we're going to be writing code in every day.



> and fear =E2=80=94 have trained many newbies in programming =E2=80=94 tha=
t it will cause
> newbies who see PHP to think it is too complex for them to consider
> learning.
>


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.




> 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=
?
>


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.




> Alternately, why not use this (which is probably the best option IMO)?:
>
> function foo() attributes
>         SingleArgument("Hello"),
>         Another\SingleArgument("World"),
>         \My\Attributes\FewArguments("foo", "bar") {}
>


This particular example leads to complications with how different keywords
stack up; would the return statement come before the "attributes" keyword?
if attributes were allowed on anonymous functions, would they come before
or after the use () clause? The traditional placement above the declaration
line keeps attributes out of the way of the main information about the
function.


It's also worth noting that all the other languages referenced in the RFC
use punctuation, rather than keywords, for their equivalent functionality:

C#: [Foo]
Rust: #![Foo] or #[Foo]
C++: [[Foo]]
Java: @Foo
ECMAScript (proposed): @Foo
Go: `Foo` or "Foo"
Doctrine et al: /** @Foo */
Hack: <<Foo>>


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.


Regards,
--=20
Rowan Tommins
[IMSoP]

--0000000000002449c105a07df45b--