Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108082
MIME-Version: 1.0
References: <CAF+90c_PXAa8PSBzULa0WHViQ-XvuX+BuYQfx6c1zOf-9pOA=A@mail.gmail.com>
 <13CC52AA-7690-42C6-89B7-B8FA4166BF38@newclarity.net> <57c08851-e6e2-c0bd-76e1-f7a0388d64b4@ralphschindler.com>
 <60610660-2E38-47BD-A998-1E226CEB3701@newclarity.net> <CAJW__o0HrU8pxduHEj7-FrVehewfKj=+LToPOJ9JHM0T6VpOkg@mail.gmail.com>
 <032B5597-6CB6-4F5E-BDDC-8A508C3FCE93@newclarity.net>
In-Reply-To: <032B5597-6CB6-4F5E-BDDC-8A508C3FCE93@newclarity.net>
Date: Fri, 10 Jan 2020 00:30:11 +0200
Message-ID: <CAJW__o2ofY0Rr3j+Rc67JYvWCt800BGH+OPNg1H_zJEPGLXt8A@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Ralph Schindler <ralph@ralphschindler.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Allow ::class on objects
From: kalle@php.net (Kalle Sommer Nielsen)

Den tor. 9. jan. 2020 kl. 23.30 skrev Mike Schinkel <mike@newclarity.net>:
>
> > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <mike@newclarity.ne=
t>:
> >
> > Traits are compiler assisted code copy/paste and not contracts (unlike
> > interfaces), so there is no gain in having ::trait.
>
> It can already be referring to using ::class so it makes little sense to =
disallow ::trait unless there is a different reason not to add another ::ke=
yword.

It is not about adding a new keyword; the keyword "trait" already
exists and "::trait" is a combination of an operator and an already
existing keyword (since we are educating each other). I cannot see any
benefits to adding the ::trait syntax (nor the ::interface) one
besides some OCD issue that you are using ::class on an instance or
name of something that technically is not a class, like in your below
example, even less when ::class already is working.

> Traits are symbols, so it is not unreasonable that there would be a way t=
o access it symbolically so that the reference can be type checked.

That is where you are wrong, traits are not contracts, so therefore
they are not types. You cannot check that a class reuses a trait or
not when it is constructed because it is compiler assisted copy/paste.
They are a useless symbol to refer to in the context of ::class. I can
understand you wish to make a helpful error message to a developer who
fails to write a class that is loadable by your runtime, but in your
example you are still refering to the trait as it was a type, which it
technically isn't.

>
> One of my use-cases for referring to traits is to provide helpful hints i=
n error messages, i.e.:
>
> printf( '%s does not implement %s. You can easily implement that interfac=
e by using %s',
>         get_class( $this ),
>         Interfaces\Foo::interface,
>         Traits\Foo::trait,
> );
>
> But the instanceof operator does not fulfill my requirements.  I manage e=
rror triggering during development and logging during production within the=
 function. Thus I can just use the implements_interface() function to handl=
e errors automatically when I am testing an assertion vs. using it just for=
 branching.
>
> You'll note I explicitly included a third parameter `$trigger_error =3D t=
rue` in hopes people would notice, realize what I was doing and not think t=
hat I needed to be educated on the existence of instanceof.

That is fine if the instanceof operator does not do it for you, but
you could have left that last part of the comment out of the mail,
after all, it was just a tip.


--=20
regards,

Kalle Sommer Nielsen
kalle@php.net