Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108960
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> <CALKiJKq-5b=0WCMYNvMPp=Y4eiyMnr1xgBZ8fMpZhLL8Sd_GbA@mail.gmail.com>
 <A4991635-3676-442D-9E44-E72E51B13268@newclarity.net>
In-Reply-To: <A4991635-3676-442D-9E44-E72E51B13268@newclarity.net>
Date: Tue, 10 Mar 2020 17:42:34 +0000
Message-ID: <CALKiJKoEfL3AQL=hTnD3yU4agWTciNpUQhYQn0ojp6_pW+LQCQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c7f95705a083a558"
Subject: Re: [PHP-DEV] [RFC] Attributes v2
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000c7f95705a083a558
Content-Type: text/plain; charset="UTF-8"

Hi Mike,

You're right that we're bikeshedding rather, but to clarify a couple of
small points, and apologise on some others...


On Tue, 10 Mar 2020 at 16:27, Mike Schinkel <mike@newclarity.net> wrote:

>
> Saying it is a weak argument is merely opinion.
>


You are right, that was an unhelpful comment, and I apologise.



> 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.).
>


My argument - or rather, my interpretation of Guido's argument in the
quoted Python discussion - is that those keywords are individual species of
a particular thing; they're not "empty keywords" (Guido's term) saying
"here comes an access modifier", or even "here comes a property". Indeed,
we might imagine a world where attributes had been added before we had
those keywords, and the language ended up looking like this:

<< Abstract >>
class Foo {
    << Private, Static >> int $foo = 42;

    << Public, Static >> getFoo(): int {
         return self::$foo;
    }
}

Note I've omitted the "function" keyword, because unlike "public" and
"static", it doesn't modify the declaration in any way, it's just mandatory
syntax which we could do without if we wanted to.




> >  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."
>


I'm sorry it came across that way. What I should probably have said is that
I see the current language as inconsistent enough that it could be used to
argue for either position; my examples were intended to demonstrate
variety, rather than any particular pattern.

That said, I didn't give enough thought to your point about declarations
being different from statements; I don't find it fully convincing, but
you're right that it makes a lot of my examples irrelevant.





> > 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.
>


Possibly; if so, that would fall into the "didn't even consider it" case.
That clearly wasn't the case for Python, though, so there's at least one
discussion we can learn from.


> And the languages that did not use @ are generally for the more advanced
developers.

I'm not sure that makes sense. C# is sometimes mocked as "Microsoft Java",
and very much targets the same use cases, so it's interesting that they
didn't copy the syntax here.


> That said, as it seems I am the only one on the list who has commented
that really dislikes this syntax

You could equally say I'm the only on the list who is actively defending
it. If you look at discussions of the RFC off-list, "nice idea, horrible
syntax" is a recurring theme, so exploring alternatives is definitely
worthwhile.


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000c7f95705a083a558--