Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108946
MIME-Version: 1.0
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>
In-Reply-To: <3E1ABF22-ACB5-4952-AE11-F842D76F8B4C@newclarity.net>
Date: Tue, 10 Mar 2020 12:33:09 +0000
Message-ID: <CALKiJKq-5b=0WCMYNvMPp=Y4eiyMnr1xgBZ8fMpZhLL8Sd_GbA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002c822305a07f538b"
Subject: Re: [PHP-DEV] [RFC] Attributes v2
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000002c822305a07f538b
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Mar 2020 at 11:46, Mike Schinkel <mike@newclarity.net> wrote:

> > On Mar 10, 2020, at 7:36 AM, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
> > I think that applies to our case equally: any punctuation or keyword is
> > just a separator between the main function declaration and the specific
> > attribute being applied. Having to write "attribute Sealed" would be like
> > having to write "visibility public"; as much as possible, we want
> "Sealed"
> > to be the keyword, and the rest of the syntax to just be formatting.
>
> No, you are making a flawed comparison.
>
> There are only three (3) visibility modifiers in PHP whereas there are
> practically *infinite* potential attribute classes.
>


Yes, it's a slight exaggeration, I was just trying to expand on the quote
from Guido van Rossum; you can read his full response here:
https://mail.python.org/pipermail/python-dev/2004-September/048518.html

His example actually uses the infinite variety of decorators as a reason to
minimise the syntax:

> A classmethod or staticmethod decorator adds a completely different
flavor than a decorator that provides an
> external linkage hint for ObjC, or one that adds synchronization, or one
that declares deprecation.


Anyway, the main reason I linked the Python discussion was to see what
talking points were raised, and that was pulled out in the PEP and I
thought was interesting.



> > 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?


Sure, if people agree it provides those things. I personally don't, but
that's fine, not everyone's going to agree.


> Consistency with other declarations in PHP?


I think this is generally a weak argument, because we have a mixture of
punctuation and keywords already. We use { and } to denote blocks, not
begin and end keywords; 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.

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.
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", and there are people who would prefer to write "public
foo() {}" rather than "public function foo() {}".


I 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.


> 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.

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. That means either:

* 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

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.


Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000002c822305a07f538b--