Re: Is there an RFC/discuss ion for ::class being a specific type?

On 16 November 2021 23:02:59 CET, Kamil Tekiela <tekiela246@gmail.com> wrote: >Hi Dusk, > >Perhaps, you misunderstood me. Take a look at the documentation >https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class >::class is just a compile time transformation. It will give you the fully >qualified name of *something* as a string literal. The only exception to >this is when using ::class on objects, as this is a runtime transformation, >and when using with keyword static. > >When ::class is used with a class name, it will give you the name of that >class as a string. When used with a name of a function, it will give you >the name of that function as a string. When used with a string, it will >give you that string as a string. >See this example https://3v4l.org/EKnEd > >The fact that this gives you a callable is just coincidental with all >strings being callable in PHP. The reason why it works right now is >because a string can represent a name of a class, interface, trait or >function. >If we were to replace the transformation with something else, like it is >proposed here, we would have to ensure that it is as versatile as a plain >string. Otherwise we would be losing functionality. In my opinion, this is extremely unintuitive and surprising. I would not have expected this to work, and would consider this more of an unintended side effect rather than an actual feature of ::class. In my opinion, this is an argument for ::class producing a ClassName type, and for migrating such code that misuses it for functions to the first-class callable syntax (ie. strlen(...)). It might be even possible to issue a deprecation warning whenever a ClassName is coerced to a callable - I am not sure how feasible it would be to implement this, however.