Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108957
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CALKiJKq-5b=0WCMYNvMPp=Y4eiyMnr1xgBZ8fMpZhLL8Sd_GbA@mail.gmail.com>
Date: Tue, 10 Mar 2020 12:27:46 -0400
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A4991635-3676-442D-9E44-E72E51B13268@newclarity.net>
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <2227A758-3035-4A43-974C-C4461A096DFB@newclarity.net>
 <CALKiJKqD=rZLN9r999byR=bDVhjiKLJ1ODKqZbwmfY9AojooSg@mail.gmail.com>
 <CALKiJKqQJFQaZp91DLy2bb9tWgwtoAfkWZq9yHpqY+sDeNkvDA@mail.gmail.com>
 <3E1ABF22-ACB5-4952-AE11-F842D76F8B4C@newclarity.net>
 <CALKiJKq-5b=0WCMYNvMPp=Y4eiyMnr1xgBZ8fMpZhLL8Sd_GbA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Attributes v2
From: mike@newclarity.net (Mike Schinkel)

> On Mar 10, 2020, at 8:33 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:

You make it really hard to just let the discussion just stand.

>> Consistency with other declarations in PHP?
>=20
> I think this is generally a weak argument, because we have a mixture =
of
> punctuation and keywords already.

Saying it is a weak argument is merely opinion. You are grasping for =
reasons to claim that.

Yes we are talking opinion on both sides, but you are presenting your =
opinion as somehow more authoritative with the "weak argument" claim.  =
To wit...

> We use { and } to denote blocks, not begin and end keywords;=20

Begin and end are not declarations in any language. Those are statements =
to delineate blocks of code.

> we keep on adding operators because people prefer them over function =
syntax; and the biggest complaint with the lambda syntax
> was that people wanted to *remove* the "fn" keyword.

Those are closures for anonymous functions. They represent a callable =
value, they are not declarations of named symbols nor references to =
named symbols.

> You mention properties as not having sigils, but we don't have a =
"property" keyword either; we have an optional "var", but I'm not clear =
why that was
> un-deprecated, because the syntax "visibility $name" is always =
sufficient.

Pedantry notwithstanding, clearly I was speaking of "public", "private", =
and "protected" (as well as "var", but I know that most PHP prefer the =
visibility modifiers instead.).=20

All of those are keywords.

> And although we write "class Foo extends Bar" where other languages =
would have "class Foo: Bar", we write "function foo(): Bar" rather than =
"function
> foo() returns Bar"

Minimally because we need the terseness in type hints for parameter =
lists.=20

It would be inconsistent to use colon in parameters lists and then =
`returns` in function declarations.

> and there are people who would prefer to write "public foo() {}" =
rather than "public function foo() {}".

Makes sense where it can be unambiguous. Note that there is still a =
keyword there, not a sigil.

>  think it makes more sense to evaluate the syntax *for this specific =
case*, rather than trying to compare it to other decisions we've made in =
the past.

Sorry, but that feels really ironic. You point me to past decisions when =
it support your argument, but when it does not you suggest that we =
evaluate "for the specific case."

>> 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.
>=20
> We should learn from other languages rather than blindly copying them, =
but
> it's interesting that I've yet to see one which adopted a =
keyword-based
> approach.

This one is true.  All other C-based languages appear to use @Foo, or =
[Foo] for C#.

But we can't use those.  And since we can't it is not clear why we could =
not consider keywords just because all other languages had the @sign or =
the [] available.

> That means either:
>=20
> * They didn't even consider a keyword approach
> * They considered a keyword approach, but rejected it for reasons that
> don't apply to PHP
> * They considered a keyword approach, but rejected it for reasons that =
we
> should at least consider
>=20
> Before we go down the path of being the one language which does it
> differently, we should at least examine which of those is the case.

Most likely because Java chose "@" so most everyone copied it.  And the =
languages that did not use @ are generally for the more advanced =
developers.

Whatever the case it does not seem to me that this is the type of case =
where we could really go wrong no matter which we pick.  Either sigils =
or keywords would work, it does not seem like something that needs =
exhaustive research.

That said, as it seems I am the only one on the list who has commented =
that really dislikes this syntax I will let this die if you can just let =
it die too because at this point we are both bikeshedding.

-Mike
P.S. Another approach would be to use at-sign+colon. e.g.  "@:Foo"=