Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108081
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: Thu, 9 Jan 2020 19:04:15 -0300
Message-ID: <CAOsHV+t1e4F5+=Y-19fvB5=x572YDWf72Qm3YHGuEgZo_oHPhQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Kalle Sommer Nielsen <kalle@php.net>, Ralph Schindler <ralph@ralphschindler.com>, 
	Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Allow ::class on objects
From: marcio.web2@gmail.com (Marcio Almada)

About the proposal itself of allowing `($expression)::class`, I'd be in favor.

>
> > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <mike@newclarity.net>:
> >
> > 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 ::keyword.
>
> Traits are symbols, so it is not unreasonable that there would be a way to access it symbolically so that the reference can be type checked.
>
> One of my use-cases for referring to traits is to provide helpful hints in error messages, i.e.:
>

Regarding the inclusion of new keywords with similar behavior of `:class`:

Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface`
cause a run time error? If I'm not mistaken `::class` can't trigger
error because it can't trigger autoload like `class_exists()` calls
does.

Currently `::class` can be used to resolve any name like
`trim::class`. IMMO it would be weird to have `::class` with the
current no autoload / error free behavior and then `::trait`,
`::function` and `::interface` triggering autoload and emitting some
error level.

And also it would be weird to have `::trait`, `::function` and
`::interface` with the same loose behavior as `::class`, in that case,
it seems less surprising to have just `::class` everywhere instead.