Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108085
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> <CAOsHV+t1e4F5+=Y-19fvB5=x572YDWf72Qm3YHGuEgZo_oHPhQ@mail.gmail.com>
 <F9482F0F-2C57-4279-80D4-92FA58C1A248@newclarity.net>
In-Reply-To: <F9482F0F-2C57-4279-80D4-92FA58C1A248@newclarity.net>
Date: Thu, 9 Jan 2020 20:53:23 -0300
Message-ID: <CAOsHV+uRCq8ZU-1cd249LQH+GTF8ehKjfOR8h-ESQB7J0O1iuA@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: 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)

>
> Hey Marco,
>
> > On Jan 9, 2020, at 5:04 PM, Marcio Almada <marcio.web2@gmail.com> wrote:
> >
> > 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.
>
> You are absolutely correct.  I am so used to PhpStorm highlighting issues that I sometimes assume that PHP will throw an error/warning for the same.
>
> So if ::interface and ::trait were added, then (tools like) PhpStorm could have enough information to flag them if developers misspell them or they are otherwise unknown.
>
> > And also it would be weird to have `::trait`, `::function` and
> > `::interface` with the same loose behavior as `::class`
>
> Why weird?
>

Because we would be expanding a construct that already looks
inappropriate from a purely
semantic POV with aliases that also would allow inappropriate usage
`some_function::interface`.
I'd rather have a generally unsatisfying construct than a set of
"denormalized" constructs with
equal potential for human inaccuracy.

Perhaps the problem is that `::class` was not exactly a good language
design decision in the first place or maybe
it made more sense in the past and as the language evolved it started
to appear to be named poorly.

A more _general_ construct like a `nameof` operator, as we have in C#,
could have been a brighter idea. See:

- https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof
- https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#nameof-expressions

> I can only assume Foo::trait vs. Bar::interface vs. Baz::class would not be hard to grok, and that it would would provide more valuable information to a reader than Foo::class vs. Bar:: class vs. Baz::class.
>
> > in that case, it seems less surprising to have just `::class`
> > everywhere instead.
>
> How so?  I was very surprised when I first realized that I could do MyInterface::class, but I would not have been surprised by MyInterface::interface.
>

Others could say they get more astounded with `SomeTrait::function`
being equally valid. It's much easier to explain that `::class` is
general and works everywhere (even though I don't think it's good).

> > `::function`
>
> That said you bring up one I did not but would also like ::function as well as `::method` and even ::var or ::variable and ::const or ::constant.
>

Hahaha You're welcome :P

Marcio