> On 17 Nov 2021, at 00:22, André Hänsel wrote:
>
> It is common (with DI systems for example) and to my knowledge not
> particularly discouraged to have function parameters that are supposed to
> accept something like Foo::class, which currently is a string.
>
> It seems logical to ask for
>
> For example, this is valid:
>>
>> echo "string"::class;
>>
>
> What! Why is it allowed when it gives the same as string::class, and
> $string::class is an error? https://3v4l.org/hfvXm#v8.1rc3
>
Sorry I forgot the namespace... so it really gives the same as "string".
>
> For example, this is valid:
>
> echo "string"::class;
>
What! Why is it allowed when it gives the same as string::class, and
$string::class is an error? https://3v4l.org/hfvXm#v8.1rc3
--
Guilliam Xavier
On Nov 16, 2021, at 14:02, Kamil Tekiela wrote:
> When used with a name of a function, it will give you the name of that
> function as a string.
Again, this is not true. Names of classes and functions are not resolved the
same way. Consider:
namespace Some\Namespace;
use function
On 16 November 2021 23:02:59 CET, Kamil Tekiela 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
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
On Nov 16, 2021, at 10:56, Kamil Tekiela wrote:
> Ok, but a popular usage is also with functions. For example, strlen::class.
> What should the compiler use in this case?
Popular in what context?
I'm not sure this usage is even correct. strlen::class isn't the name of the
strlen function; it's
> Le 16 nov. 2021 à 18:34, Kamil Tekiela a écrit :
>
>
> At the moment, ::class is just a preprocessor macro. It is not part of the
> runtime.
This is not true in general. For example `static::class` is not resolvable at
compile-time.
(In fact, many years ago, when I played with that new
Ok, but a popular usage is also with functions. For example, strlen::class.
What should the compiler use in this case?
Replacing a string with an object of a strigable class is not the same. Say
I have code like this:
function callFoo(callable $func) {
echo $func('bar');
}
Maybe I'm missing something but now that you said it's kind of a macro, I think
it would actually be pretty easy to implement, at least when not taking
backwards compatibility or performance into account:
class ClassName {
private $name;
function __construct(string $name) {
$this->name
Interesting, but what would such a type actually be? How would PHP check
the type? What would be the rules?
At the moment, ::class is just a preprocessor macro. It is not part of the
runtime. It also doesn't mean the name of the class. It just means "textual
representation of the value on the
Hey André,
On Tue, Nov 16, 2021 at 6:22 PM André Hänsel wrote:
> It is common (with DI systems for example) and to my knowledge not
> particularly discouraged to have function parameters that are supposed to
> accept something like Foo::class, which currently is a string.
>
> It seems logical
It is common (with DI systems for example) and to my knowledge not
particularly discouraged to have function parameters that are supposed to
accept something like Foo::class, which currently is a string.
It seems logical to ask for a special type that can hold class names, so
that parameters that
13 matches
Mail list logo
