# Add support $object::class

- Thread: https://externals.io/message/85967
- Original archive: https://news-web.php.net/php.internals/85967
- Started by S.A.N on 2015-04-27T11:18:46+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #85967 — S.A.N — 2015-04-27T11:18:46+00:00

URL: https://externals.io/message/85967#85967

Now this code causes an error PHP 5-7.

PHP Parse:
Syntax error, unexpected 'class' (T_CLASS), expecting identifier
(T_STRING) or variable (T_VARIABLE) or '{' or '$'

Do not want to use get_class($object)

Thank.

---

## #85968 — Anthony Ferrara — 2015-04-27T15:35:54+00:00

URL: https://externals.io/message/85967#85968 · In reply to: #85967

> Now this code causes an error PHP 5-7.
>
> PHP Parse:
> Syntax error, unexpected 'class' (T_CLASS), expecting identifier
> (T_STRING) or variable (T_VARIABLE) or '{' or '$'
>
> Do not want to use get_class($object)

Why not?

Seriously, why not? ::class was added because there was no easy way to
get from the symbol class name to the string representation of it (you
couldn't pass it to a function, etc since it would look like a
constant). So ::class is a purely compile time construct to turn a
literal classname into a string representation.

However, if you have a variable, there already is a way to do that at
runtime: get_class. What's the problem with that where we need to
further support arbitrary syntax?

Note: I'm not saying we shouldn't add support. I'm just saying that
it's not the same situation as with Bar::class...

Anthony

---

## #85970 — Marco Pivetta — 2015-04-27T17:25:32+00:00

URL: https://externals.io/message/85967#85970 · In reply to: #85968

> 
> > […]
>
> Why not?
>
> Seriously, why not? ::class was added because there was no easy way to
> get from the symbol class name to the string representation of it (you
> couldn't pass it to a function, etc since it would look like a
> constant). So ::class is a purely compile time construct to turn a
> literal classname into a string representation.


Mainly due to overhead.

Having `::class` accessible even for objects and variables containing class
names would be very efficient, as it saves us a method call for an
operation that really doesn't need one.

Systems that depend on `get_class()` a lot would benefit from such a
feature: see for example mapping caches in data mappers and handlers
matching in event handlers.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #85971 — S.A.N — 2015-04-27T17:28:57+00:00

URL: https://externals.io/message/85967#85971 · In reply to: #85968

> Why not?
>
> Seriously, why not? ::class was added because there was no easy way to
> get from the symbol class name to the string representation of it (you
> couldn't pass it to a function, etc since it would look like a
> constant). So ::class is a purely compile time construct to turn a
> literal classname into a string representation.
>
> However, if you have a variable, there already is a way to do that at
> runtime: get_class. What's the problem with that where we need to
> further support arbitrary syntax?
>
> Note: I'm not saying we shouldn't add support. I'm just saying that
> it's not the same situation as with Bar::class...


1. get_class($object) - looks bad and long
2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
3. Function call get_class($object) is slower

---

## #85972 — Nicolas Grekas — 2015-04-27T17:33:03+00:00

URL: https://externals.io/message/85967#85972 · In reply to: #85970

> Systems that depend on `get_class()` a lot would

An for non-objects types, I suggest that $var::class could return the same
as get_type($var). That would allow saving ref mismatches when $var is a
ref.

---

## #85973 — S.A.N — 2015-04-27T17:35:04+00:00

URL: https://externals.io/message/85967#85973 · In reply to: #85972

2015-04-27 20:33 GMT+03:00 Nicolas Grekas <nicolas.grekas@gmail.com>:
>
> > […]
>
> An for non-objects types, I suggest that $var::class could return the same
> as get_type($var). That would allow saving ref mismatches when $var is a
> ref.

+1

---

## #85974 — Stanislav Malyshev — 2015-04-27T18:28:08+00:00

URL: https://externals.io/message/85967#85974 · In reply to: #85971

Hi!

> 1. get_class($object) - looks bad and long

There's nothing bad in calling functions. Functions are part of PHP and
are completely OK.

> 2. Illogically - Bar::class valid syntax, $object::class invalid
> syntax. 3. Function call get_class($object) is slower

Unless you code is doing get_class literally millions of times, and it's
basically all it does, it does not matter. This kind of "optimization"
does not lead to anything but ugly code and waste of time.

-- 
Stas Malyshev
smalyshev@gmail.com

---

## #85975 — Rowan Collins — 2015-04-27T18:39:20+00:00

URL: https://externals.io/message/85967#85975 · In reply to: #85970

Marco Pivetta wrote on 27/04/2015 18:25:
> 
>
> > […]
>
> Mainly due to overhead.
>
> Having `::class` accessible even for objects and variables containing class
> names would be very efficient, as it saves us a method call for an
> operation that really doesn't need one.

The overhead of function calls comes up a lot, and it strikes me that 
optimising calls to built-in functions *as a category* would be better 
than piling more special case syntax into the engine for every use case.

Is this a fundamentally hard problem? Could there be some way of writing 
certain internal functions such that they're accessible as normal calls 
(for use with call_user_func etc) but also optimisable to something more 
similar to an opcode call (which seems to be the alternative) by the 
OpCache?

Presumably, $foo::class will never be as fast as Foo::class anyway, 
because the latter can happen *at compile time*, since it needs only 
follow the namespace resolution for class name "Foo" within the current 
file/block, thus having effectively zero overhead once cached.

Regards,
-- 
Rowan Collins
[IMSoP]

---

## #85976 — Marco Pivetta — 2015-04-27T19:53:07+00:00

URL: https://externals.io/message/85967#85976 · In reply to: #85975

> Marco Pivetta wrote on 27/04/2015 18:25:
>
> > […]
>
> The overhead of function calls comes up a lot, and it strikes me that
> optimising calls to built-in functions *as a category* would be better than
> piling more special case syntax into the engine for every use case.
>

Yes, it could be done indeed.

Presumably, $foo::class will never be as fast as Foo::class anyway, because
> the latter can happen *at compile time*, since it needs only follow the
> namespace resolution for class name "Foo" within the current file/block,
> thus having effectively zero overhead once cached.
>

It will never be, but still, following works, and that means that we have
some sort of inconsistency: http://3v4l.org/napVW

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #86102 — Sara Golemon — 2015-04-30T23:43:16+00:00

URL: https://externals.io/message/85967#86102 · In reply to: #85971

> > […]
>
> 1. get_class($object) - looks bad and long
>
It's a function call.  A pretty much self-declarative one at that.
What is "bad" about it? For that matter, what's "long" about it?  It's
pretty short as PHP function calls go.

> 2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
>
I'll grant you the consistency argument.  I'm all for consistency, but
that's the ONLY valid reason you've stated.

> 3. Function call get_class($object) is slower
>
Not so much so that you'd notice.  Fix the performance issues which
actually make an impact first.  When you've done that, THEN come back.
(Hint: You haven't)

-Sara

---

## #86131 — Ralph Schindler — 2015-05-07T15:04:14+00:00

URL: https://externals.io/message/85967#86131 · In reply to: #86102

> > […]
> I'll grant you the consistency argument.  I'm all for consistency, but
> that's the ONLY valid reason you've stated.

Even then I think this part of the argument is fairly weak.  In 
Bar::class, the context of Bar is always a class name (either short due 
to do namespace or use statements, or long fully qualified).

$object is not guaranteed to be an object, it could be anything (int, 
string, etc) or nothing (null).  using ::class for a variable, I'd 
argue, makes for less consistency.  What would the replacement be for 
non-object variables?  An error, exception, or false, or string type? 
At least in "Bar::class", you'll always get a string representation of 
what the fully qualified class name resolves to.

That said, the argument could be made that since static::class, 
self::class, and parent::class fall into the same category of potential 
runtime resolutions that $object::class too should be supported.

-ralph

---

## #86132 — Marco Pivetta — 2015-05-07T15:13:53+00:00

URL: https://externals.io/message/85967#86132 · In reply to: #86131

>
>  2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
> > […]
>
> Even then I think this part of the argument is fairly weak.  In
> Bar::class, the context of Bar is always a class name (either short due to
> do namespace or use statements, or long fully qualified).
>
> $object is not guaranteed to be an object, it could be anything (int,
> string, etc) or nothing (null).  using ::class for a variable, I'd argue,
> makes for less consistency.  What would the replacement be for non-object
> variables?  An error, exception, or false, or string type? At least in
> "Bar::class", you'll always get a string representation of what the fully
> qualified class name resolves to.
>

Hey Ralph,

Please refer to current behavior:

http://3v4l.org/3sgLa

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #86133 — S.A.N — 2015-05-07T15:14:44+00:00

URL: https://externals.io/message/85967#86133 · In reply to: #86131

> $object is not guaranteed to be an object, it could be anything (int,
> string, etc) or nothing (null).  using ::class for a variable, I'd argue,
> makes for less consistency.  What would the replacement be for non-object
> variables?  An error, exception, or false, or string type? At least in
> "Bar::class", you'll always get a string representation of what the fully
> qualified class name resolves to.

$scalar::class === gettype($scalar)
$object::class ===  get_class($object)

> That said, the argument could be made that since static::class, self::class,
> and parent::class fall into the same category of potential runtime
> resolutions that $object::class too should be supported.

+1