[VOTE] ::class feature to resolve namespaced class names to scalars

13 years ago by Anatoliy Belsky — view source — reply

unread

Hi Ralph,

I've tested the feature/class_name_scalar in your repo on Windows. Both TS
and NTS build and pass the test.

Regards

Anatoliy

Am Di, 11.09.2012, 16:39 schrieb Ralph Schindler:

Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point, I've gotten some positive feedback from various places and feel
its time to open it up for a vote to internals.
 RFC: https://wiki.php.net/rfc/class_name_scalars#vote

 PR: https://github.com/php/php-src/pull/187
Thanks,
Ralph

13 years ago by Dmitry Stogov — view source — reply

unread

Hi Ralph,

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

Thanks. Dmitry.

Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point, I've gotten some positive feedback from various places and feel
its time to open it up for a vote to internals.
 RFC: https://wiki.php.net/rfc/class_name_scalars#vote

 PR: https://github.com/php/php-src/pull/187
Thanks,
Ralph

13 years ago by Marco Pivetta — view source — reply

unread

@Dmitry that looks more like a function call, while (IMO) it is more
intuitive to consider it like a static property...

Marco Pivetta

http://twitter.com/Ocramius

http://marco-pivetta.com

Hi Ralph,

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

Thanks. Dmitry.
Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point, I've gotten some positive feedback from various places and feel
its time to open it up for a vote to internals.
 RFC: https://wiki.php.net/rfc/**class_name_scalars#vote<https://wiki.php.net/rfc/class_name_scalars#vote>

 PR: https://github.com/php/php-**src/pull/187<https://github.com/php/php-src/pull/187>
Thanks,
Ralph

13 years ago by Lars Strojny — view source — reply

unread

Hi Dmitry,

Am 13.09.2012 um 10:17 schrieb Dmitry Stogov dmitry@zend.com:
[...]

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

Wouldn’t this look too much like a function with all the implications that might cause like users expecting class($variable) to work or even class(otherfunc())?

cu,
Lars

13 years ago by Simon J Welsh — view source — reply

unread

Hi Dmitry,

Am 13.09.2012 um 10:17 schrieb Dmitry Stogov dmitry@zend.com:
[...]

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

Wouldn’t this look too much like a function with all the implications that might cause like users expecting class($variable) to work or even class(otherfunc())?

cu,
Lars

I would expect $variable::class to work (like late static bindings). However, I do agree that class(ClassName) just looks off and makes it look like you can pass class names to functions.

Simon Welsh
Admin of http://simon.geek.nz/

13 years ago by Lars Strojny — view source — reply

unread

Hi Simon,

Am 13.09.2012 um 10:34 schrieb Simon J Welsh simon@simon.geek.nz:
[...]

I would expect $variable::class to work (like late static bindings).
[...]

Than better try the patch, as it doesn’t work now :)

But it is a good point indeed. @Ralph: what do you think?

cu,
Lars

13 years ago by jpauli — view source — reply

unread

Hi Simon,

Am 13.09.2012 um 10:34 schrieb Simon J Welsh simon@simon.geek.nz:
[...]

I would expect $variable::class to work (like late static bindings).
[...]

Than better try the patch, as it doesn’t work now :)

But it is a good point indeed. @Ralph: what do you think?

Perhaps get_class_fqn(string:ClassName) ?

Julien.P

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

Perhaps get_class_fqn(string:ClassName) ?

Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Ralph Schindler — view source — reply

unread

Perhaps get_class_fqn(string:ClassName) ?

Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.

I personally think we should keep resolutions as much to compile time as
possible.

Your suggestion implies that we now have either a function and a new
keyword, or two new keywords: get_class_fqn, and ClassName.

I like that ::class is basically 7 chars for a FQ name resolution at
compile time, after all, point of this is that we can leverage
namespacing in scalars/string when referring to classes as strings.

-ralph

13 years ago by Dmitry Stogov — view source — reply

unread

We already have isset(), empty(), unset() that are a special purpose
functions handled by compiler.

Thanks. Dmitry.

Hi Dmitry,

Am 13.09.2012 um 10:17 schrieb Dmitry Stogov dmitry@zend.com:
[...]

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

Wouldn’t this look too much like a function with all the implications that might cause like users expecting class($variable) to work or even class(otherfunc())?

cu,
Lars

13 years ago by jpauli — view source — reply

unread

We already have isset(), empty(), unset() that are a special purpose
functions handled by compiler.

Thanks. Dmitry.

Yes, if we communicate the right way about our feature not beeing a
true PHP function and taking isset(), empty() et all as examples,
people would understand I think :)

Julien.P

Hi Dmitry,

Am 13.09.2012 um 10:17 schrieb Dmitry Stogov dmitry@zend.com:
[...]

I think the syntax is wired.
Instead of classname::class I would prefer something like
class(classname).

Wouldn’t this look too much like a function with all the implications that
might cause like users expecting class($variable) to work or even
class(otherfunc())?

cu,
Lars

13 years ago by Lars Strojny — view source — reply

unread

Hi Dmitry,

Am 13.09.2012 um 11:12 schrieb Dmitry Stogov dmitry@zend.com:

We already have isset(), empty(), unset() that are a special purpose functions handled by compiler.
[...]

That’s exactly my point: these special purpose functions present themself to the user as usual functions and set a certain expectation. That’s why we now allow empty(func()). If something presents itself as a syntax element, there is no such expectation and the only valid software metric, WTFs per minute decreases slightly.

cu,
Lars

13 years ago by Ralph Schindler — view source — reply

unread

I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).

I am not a big fan of the syntax class(ShortClass\Name) as to me it
looks like a function call.

Personally, I like drawing parallels from the same languages that I
think helped shaped PHP's object-model. In this case, the Java has a
similar enough feature where Type.class returns a class object (in our
case we just need to return a string of the FQ class name).

Your suggestion is similar to that of, I think, C# where
typeof(SomeClassName) would return a reflection-like/type object where
you could get the FullName():

http://msdn.microsoft.com/en-us/library/58918ffs%28v=vs.71%29.aspx

I could go either way, at this point (after the April discussion on the
matter), I had not really given much thought to class() lang. construct.

Personally, ::class feels a bit better to me in that the context feels
more "compile-time", like CLASS, and the NS resolutions, than does
class() that you suggest.

From a wider perspective, I've seen these variations in the wild:

class Foo {
const CLASSNAME = CLASS;
// or
const _class = CLASS;
}

Which allows for the usage:

Foo::CLASSNAME;

for example.

FWIW, both reusing the class() keyword making it BC, which is something
I like.

-ralph

13 years ago by Dmitry Stogov — view source — reply

unread

Hi Ralph,

You persuade me. :)

The SOMETHING::class syntax looked wired to me because I didn't
understand it.

However, the SOMETHING::class syntax might be considered as a reference
to a predefined class constant and in this case it looks quite
consistent. I suggest to reflect it in RFC and documentation (if we
agree to include it in release) to avoid future misunderstanding.

Also I would expect SOMETHING::class to work in all cases where class
constants work. e.g. self::class, parent::class, static::class,
$obj::class. To do it for parent, static and $obj you'll probably need a
new opcode - ZEND_FETCH_CLASSNAME that must be very similar to
ZEND_FETCH_CLASS. May be it's possible to do the same using
ZEND_FETCH_CONSTANT, but I don't think it makes sense to complicate the
existing opcode.

SOMETHING::class must be consistent with traits.

In case all the above works, I say +1 and even may help with implementation.

Finally, may be SOMETHING::CLASS is a bit more clear than
SOMETHING::class.

Thanks. Dmitry.

I think the syntax is wired.
Instead of classname::class I would prefer something like
class(classname).

I am not a big fan of the syntax class(ShortClass\Name) as to me it
looks like a function call.

Personally, I like drawing parallels from the same languages that I
think helped shaped PHP's object-model. In this case, the Java has a
similar enough feature where Type.class returns a class object (in our
case we just need to return a string of the FQ class name).

Your suggestion is similar to that of, I think, C# where
typeof(SomeClassName) would return a reflection-like/type object where
you could get the FullName():

http://msdn.microsoft.com/en-us/library/58918ffs%28v=vs.71%29.aspx

I could go either way, at this point (after the April discussion on the
matter), I had not really given much thought to class() lang. construct.

Personally, ::class feels a bit better to me in that the context feels
more "compile-time", like CLASS, and the NS resolutions, than does
class() that you suggest.

From a wider perspective, I've seen these variations in the wild:

class Foo {
const CLASSNAME = CLASS;
// or
const _class = CLASS;
}

Which allows for the usage:

Foo::CLASSNAME;

for example.

FWIW, both reusing the class() keyword making it BC, which is something
I like.

-ralph

13 years ago by Patrick Schaaf — view source — reply

unread

Hi,

if it looks, smells, and works like a class constant, can't just BE a class
constant, automatically created, but just as-if "const class = 'xxx';" had
been present in the definition in the first place?

Not that I know php code internals in any thorough way, but I imagine that
that approach would obviate the need for any new opcodes.

best regards
Patrick

13 years ago by Dmitry Stogov — view source — reply

unread

In general it'll work, but it'll waste memory.

Thanks. Dmitry.

Hi,

if it looks, smells, and works like a class constant, can't just BE a
class constant, automatically created, but just as-if "const class =
'xxx';" had been present in the definition in the first place?

Not that I know php code internals in any thorough way, but I imagine
that that approach would obviate the need for any new opcodes.

best regards
Patrick

13 years ago by Patrick ALLAERT — view source — reply

unread

2012/9/14 Dmitry Stogov dmitry@zend.com:

Finally, may be SOMETHING::CLASS is a bit more clear than
SOMETHING::class.

That is the reason why I voted "no", but more because of the token
used than the feature.
I previously stated that I preferred CLASS as well to be more in
line with what we currently have, I haven't changed my mind since the
arguments provided didn't convinced me at all.

Cheers,
Patrick

13 years ago by Ryan McCue — view source — reply

unread

Patrick ALLAERT wrote:

2012/9/14 Dmitry Stogov dmitry@zend.com:

Finally, may be SOMETHING::CLASS is a bit more clear than
SOMETHING::class.

That is the reason why I voted "no", but more because of the token
used than the feature.
I previously stated that I preferred CLASS as well to be more in
line with what we currently have, I haven't changed my mind since the
arguments provided didn't convinced me at all.

I somewhat agree; using CLASS would make it more obvious that it's
compile-time rather than runtime, IMO.

--
Ryan McCue
<http://ryanmccue.info/

13 years ago by Ralph Schindler — view source — reply

unread

I somewhat agree; using CLASS would make it more obvious that it's
compile-time rather than runtime, IMO.

It's not always going to be compile-time.

For self::class and Foo::class, it will be compile time every time. For
static:class and parent::class, that has to be done at runtime as the
class_entry is not completely hooked up (active_class_entry does not
have parent* pointer, even if the class is extended).

The 99% use case is: Foo::class, where a short name can be resolved
against the current namespace and current import/use statements.

The rest of the use cases, as we've seen, are going to be filled out for
consistency.

That means that:

class Foo {
const SOMECLASSNAME = static::class; // or parent::class
}

Will/should result in an E_FATAL (this use case doesn't really make a
ton of sense anyway, but people are likely to do it).

(I think the same applies for method signatures too, btw.)

That is the reason why I voted "no", but more because of the token
used than the feature.
I previously stated that I preferred CLASS as well to be more in
line with what we currently have, I haven't changed my mind since the
arguments provided didn't convinced me at all.

I guess I can't convince preference :)

I prefer ::class over ::class, and in that only marginally, because
its shorter. After all, the whole point of this feature is because
people are using namespaces (for the shortness of class names) and they
need to use long class names as string, but want all the benefits of the
namespacing/aliasing in the current scope.

-ralph

13 years ago by Jan Dolecek — view source — reply

unread

I'm not able to try it myself at the moment and it's not described in the
RFC, so I'd like to ask:

Will it invoke autoloading, if the class does not exist (yet)?

I think this should be considered. If so, it's not good as it kills
lazy-loading. If not so, it we may get errors later than expected.
I think these problems deserve discussion. (I'd prefer to keep
lazy-loading, since existence of class gets validated by IDE)

Regards,
JD

On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
ralph@ralphschindler.comwrote:

Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this point,
I've gotten some positive feedback from various places and feel its time to
open it up for a vote to internals.
RFC: https://wiki.php.net/rfc/**class_name_scalars#vote<https://wiki.php.net/rfc/class_name_scalars#vote>

PR: https://github.com/php/php-**src/pull/187<https://github.com/php/php-src/pull/187>
Thanks,
Ralph

13 years ago by Marco Pivetta — view source — reply

unread

Hi JD,

I'm not able to try it myself at the moment and it's not described in the
RFC, so I'd like to ask:

Will it invoke autoloading, if the class does not exist (yet)?

I think this should be considered. If so, it's not good as it kills
lazy-loading. If not so, it we may get errors later than expected.
I think these problems deserve discussion. (I'd prefer to keep
lazy-loading, since existence of class gets validated by IDE)

Regards,
JD

On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
ralph@ralphschindler.comwrote:
Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point,
I've gotten some positive feedback from various places and feel its time
to
open it up for a vote to internals.
RFC: https://wiki.php.net/rfc/**class_name_scalars#vote<
https://wiki.php.net/rfc/class_name_scalars#vote>;
PR: https://github.com/php/php-**src/pull/187<
https://github.com/php/php-src/pull/187>;

Thanks,
Ralph

--

I don't think autoloading is needed here, since the FQCN can be resolved
without it (exactly like with type hinting).

Marco Pivetta

http://twitter.com/Ocramius

http://marco-pivetta.com

13 years ago by Lars Strojny — view source — reply

unread

Hi,

Am 13.09.2012 um 16:02 schrieb Marco Pivetta ocramius@gmail.com:

I don't think autoloading is needed here, since the FQCN can be resolved
without it (exactly like with type hinting).

Has nothing to do with autoloading. It only checks if there is a use statement. Auto-loading is triggered during call time, not during compile time.

cu,
Lars

13 years ago by Ralph Schindler — view source — reply

unread

Hi all,

I know there are few edge cases that need to be resolved. What I am
looking for in the RFC/vote is to determine if ::class (as it works in
the PoC patch) has enough acceptance for inclusion in master.

If there is not enough interest in this by the powers that be, or the
feature as currently proposed is not popular enough. I'd rather not
spend many more hours on it.

I'd like to get as much direction as possible from people so we can
close out the edge cases and I can have some clear goals to work towards
to get the implementation (including all edge cases) ready to be merged.

That said, here is a summary:

The VOTE is for whether entertaining ::class would make it into
master, it has little to do with edge cases.
Here are the edge cases / implementation details that need a decision:
- $variable::class (should it even be supported?)
- self, static, parent::class not in a class definition
- self, static, parent::class in a method signature
- self, static, parent::class in a method body
- if static & parent are runtime, do we return false on misses?

-ralph

Hi internals!

The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point, I've gotten some positive feedback from various places and feel
its time to open it up for a vote to internals.
 RFC: https://wiki.php.net/rfc/class_name_scalars#vote

 PR: https://github.com/php/php-src/pull/187
Thanks,
Ralph

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

Here are the edge cases / implementation details that need a decision:

$variable::class (should it even be supported?)

I don't see it doing anything useful.

self, static, parent::class not in a class definition

self, static, parent::class in a method signature

self, static, parent::class in a method body

In constant context, self:: may work, but static:: can't work for
obvious reasons. parent:: can be made work too I think - though the
class may not be known at the run time, its name should be.

As for runtime context, static:: can be made work too but I wonder why
bother if we have perfectly good get_called_class()...

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Ralph Schindler — view source — reply

unread

Hey Stas,

Here are the edge cases / implementation details that need a decision:

$variable::class (should it even be supported?)

I don't see it doing anything useful.

I generally agree.

In the current patch, this does not work and would need another run in
the parser.

- self, static, parent::class not in a class definition
- self, static, parent::class in a method signature
- self, static, parent::class in a method body
In constant context, self:: may work, but static:: can't work for
obvious reasons. parent:: can be made work too I think - though the
class may not be known at the run time, its name should be.

self works in compile-time in the current patch.

static::class and parent::class work in the current patch in run-time,
but they are effectively doing a get_called_class() and
get_parent_class() respectively.

This part of my implementation can be cleaned up to remain in runtime
but utilize zend_do_fetch_class() instead.

As for runtime context, static:: can be made work too but I wonder why
bother if we have perfectly good get_called_class()...

For some people, I think it's a matter of completeness, regardless if it
is a compile-time name resolution or a runtime class lookup.
Personally, (I am not the majority here I feel), I'd rather see
zend_error(E_FATAL) for any runtime lookups, forcing people to use the
runtime-lookup-isms (like get_called_class(), or get_parent_class()).
For the latter, returning "false" there seems more likely, where as
parent::class returning false when not in an inherited class seems odd
to me.

-ralph

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

In the current patch, this does not work and would need another run in
the parser.

Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for
it, I'm just saying if we wanted it...

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Etienne Kneuss — view source — reply

unread

Hi,

Hi!

In the current patch, this does not work and would need another run in
the parser.

Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for
it, I'm just saying if we wanted it...

Even though it's not really useful, we should have it for the sake of
consistency.

As long as it doesn't cause major technical complications to
implement, I don't see why we shouldn't have that available.

Best,

--
Etienne Kneuss

13 years ago by Pierre Joye — view source — reply

unread

hi Ralph,

Given the current discussions and the few votes, I would recommend to
move this RFC back to the discussion phase, clear the open questions
(syntax or other) again before moving back to vote.

Cheers,

On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
ralph@ralphschindler.com wrote:

Hi internals!

The ::class resolution proposal had significant discussion in April and I've
updated the patch to address issues that came up then. At this point, I've
gotten some positive feedback from various places and feel its time to open
it up for a vote to internals.
RFC: https://wiki.php.net/rfc/class_name_scalars#vote

PR: https://github.com/php/php-src/pull/187
Thanks,
Ralph

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Ralph Schindler — view source — reply

unread

That is what I will do.

What has become clear to me is that this feature does indeed have a lot
of promise, and me working on it further to address new concerns (and
directions) would not be wasted time.

I will close the vote, clean up the patch to address new concerns, then
bring this back to a vote again at a later date.

-ralph

hi Ralph,

Given the current discussions and the few votes, I would recommend to
move this RFC back to the discussion phase, clear the open questions
(syntax or other) again before moving back to vote.

Cheers,

On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
ralph@ralphschindler.com wrote:
Hi internals!

The ::class resolution proposal had significant discussion in April and I've
updated the patch to address issues that came up then. At this point, I've
gotten some positive feedback from various places and feel its time to open
it up for a vote to internals.
 RFC: https://wiki.php.net/rfc/class_name_scalars#vote

 PR: https://github.com/php/php-src/pull/187
Thanks,
Ralph

[VOTE] ::class feature to resolve namespaced class names to scalars

I would expect $variable::class to work (like late static bindings). However, I do agree that class(ClassName) just looks off and makes it look like you can pass class names to functions.

Reference to "late static binding" is even more confusing - if you mean
that $variable is object, then the binding is not "static" - since you
have an object - and you have perfectly good get_class($variable) to do
that. Is that what you were meaning?

I guess it can be made work if we do it right - e.g. via
ZEND_FETCH_CONSTANT. I'm not a big fan of inventing new syntax for
things that already exist and can be done with the same effort - but
technically it should be possible.

[VOTE] ::class feature to resolve namespaced class names to scalars

I would expect $variable::class to work (like late static bindings). However, I do agree that class(ClassName) just looks off and makes it look like you can pass class names to functions.

Reference to "late static binding" is even more confusing - if you mean that $variable is object, then the binding is not "static" - since you have an object - and you have perfectly good get_class($variable) to do that. Is that what you were meaning?

I guess it can be made work if we do it right - e.g. via ZEND_FETCH_CONSTANT. I'm not a big fan of inventing new syntax for things that already exist and can be done with the same effort - but technically it should be possible.

Reference to "late static binding" is even more confusing - if you mean
that $variable is object, then the binding is not "static" - since you
have an object - and you have perfectly good get_class($variable) to do
that. Is that what you were meaning?

I guess it can be made work if we do it right - e.g. via
ZEND_FETCH_CONSTANT. I'm not a big fan of inventing new syntax for
things that already exist and can be done with the same effort - but
technically it should be possible.