# [VOTE] ::class feature to resolve namespaced class names to scalars - Thread: https://externals.io/message/62949 - Original archive: https://news-web.php.net/php.internals/62949 - Started by Ralph Schindler on 2012-09-11T14:39:47+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/62949.md?page=2 - 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 --- ## #62949 — Ralph Schindler — 2012-09-11T14:39:47+00:00 URL: https://externals.io/message/62949#62949 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 --- ## #62954 — Anatoliy Belsky — 2012-09-12T09:18:51+00:00 URL: https://externals.io/message/62949#62954 · In reply to: #62949 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 --- ## #62964 — Dmitry Stogov — 2012-09-13T08:17:18+00:00 URL: https://externals.io/message/62949#62964 · In reply to: #62949 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 --- ## #62965 — Marco Pivetta — 2012-09-13T08:27:03+00:00 URL: https://externals.io/message/62949#62965 · In reply to: #62964 @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. > > > > > > […] --- ## #62966 — Lars Strojny — 2012-09-13T08:28:17+00:00 URL: https://externals.io/message/62949#62966 · In reply to: #62964 Hi Dmitry, Am 13.09.2012 um 10:17 schrieb Dmitry Stogov : [...] > 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 --- ## #62967 — Simon J Welsh — 2012-09-13T08:34:22+00:00 URL: https://externals.io/message/62949#62967 · In reply to: #62966 > Hi Dmitry, > > Am 13.09.2012 um 10:17 schrieb Dmitry Stogov : > [...] > > […] > > 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/ --- ## #62968 — Lars Strojny — 2012-09-13T08:36:14+00:00 URL: https://externals.io/message/62949#62968 · In reply to: #62967 Hi Simon, Am 13.09.2012 um 10:34 schrieb Simon J Welsh : [...] > 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 --- ## #62969 — jpauli — 2012-09-13T09:02:11+00:00 URL: https://externals.io/message/62949#62969 · In reply to: #62968 > Hi Simon, > > Am 13.09.2012 um 10:34 schrieb Simon J Welsh : > [...] > > […] > [...] > > 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 --- ## #62970 — Dmitry Stogov — 2012-09-13T09:12:17+00:00 URL: https://externals.io/message/62949#62970 · In reply to: #62966 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 : > [...] > > […] > > 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 --- ## #62971 — jpauli — 2012-09-13T09:14:34+00:00 URL: https://externals.io/message/62949#62971 · In reply to: #62970 > 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 > > > > > […] --- ## #62972 — Lars Strojny — 2012-09-13T09:16:45+00:00 URL: https://externals.io/message/62949#62972 · In reply to: #62970 Hi Dmitry, Am 13.09.2012 um 11:12 schrieb Dmitry Stogov : > 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 --- ## #62977 — Jan Dolecek — 2012-09-13T13:57:22+00:00 URL: https://externals.io/message/62949#62977 · In reply to: #62949 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 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 --- ## #62978 — Marco Pivetta — 2012-09-13T14:02:16+00:00 URL: https://externals.io/message/62949#62978 · In reply to: #62977 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 > wrote: > > > […] > point, > > […] > to > > […] > https://wiki.php.net/rfc/class_name_scalars#vote> > > […] > https://github.com/php/php-src/pull/187> > > […] > 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 --- ## #62979 — Lars Strojny — 2012-09-13T14:06:20+00:00 URL: https://externals.io/message/62949#62979 · In reply to: #62978 Hi, Am 13.09.2012 um 16:02 schrieb Marco Pivetta : > 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 --- ## #62982 — Ralph Schindler — 2012-09-13T20:51:23+00:00 URL: https://externals.io/message/62949#62982 · In reply to: #62964 > 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 --- ## #62984 — Stas Malyshev — 2012-09-13T20:52:50+00:00 URL: https://externals.io/message/62949#62984 · In reply to: #62969 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 --- ## #62985 — Stas Malyshev — 2012-09-13T20:58:01+00:00 URL: https://externals.io/message/62949#62985 Hi! > > […] What this would mean? ClassName::class has a clear meaning - ClassName is a name of the class (possibly aliased) and class is the property of this class, namely its full name. However I do not see how $variable::class can do anything meaningful. Since namespace resolution is static compile-time, $variable can not be anything but the full name of the class, so what $variable::class supposed to do? Just be equal to $variable? What's the point of such operation, what may be achieved by it? 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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62986 — Ralph Schindler — 2012-09-13T21:00:57+00:00 URL: https://externals.io/message/62949#62986 · In reply to: #62949 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 --- ## #62987 — Ralph Schindler — 2012-09-13T21:01:11+00:00 URL: https://externals.io/message/62949#62987 · In reply to: #62984 > > […] > > 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 --- ## #62988 — Anthony Ferrara — 2012-09-13T21:19:34+00:00 URL: https://externals.io/message/62949#62988 · In reply to: #62985 Stas, On Thu, Sep 13, 2012 at 4:58 PM, Stas Malyshev wrote: > Hi! > > > […] > > What this would mean? ClassName::class has a clear meaning - ClassName > is a name of the class (possibly aliased) and class is the property of > this class, namely its full name. However I do not see how > $variable::class can do anything meaningful. Since namespace resolution > is static compile-time, $variable can not be anything but the full name > of the class, so what $variable::class supposed to do? Just be equal to > $variable? What's the point of such operation, what may be achieved by it? > Right now, you can access static properties and methods from a string/object by doing $var::$foo... I would assume that this works the same way. That way, you can take in a string class name, or an object, and get the class in one shot `$obj::class` instead of `get_class($obj)`... Just for consistency... Anthony --- ## #62989 — Stas Malyshev — 2012-09-13T21:30:12+00:00 URL: https://externals.io/message/62949#62989 · In reply to: #62986 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 --- ## #62990 — Stas Malyshev — 2012-09-13T21:39:36+00:00 URL: https://externals.io/message/62949#62990 · In reply to: #62988 Hi! > Right now, you can access static properties and methods from a > string/object by doing $var::$foo... I would assume that this works the > same way. That way, you can take in a string class name, or an object, > and get the class in one shot `$obj::class` instead of > `get_class($obj)`... Just for consistency... 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #62991 — Ralph Schindler — 2012-09-13T21:41:57+00:00 URL: https://externals.io/message/62949#62991 · In reply to: #62989 Hey Stas, > > […] > 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. > > […] > > 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 --- ## #62993 — Stas Malyshev — 2012-09-13T22:24:29+00:00 URL: https://externals.io/message/62949#62993 · In reply to: #62991 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 --- ## #62994 — Etienne Kneuss — 2012-09-13T22:32:13+00:00 URL: https://externals.io/message/62949#62994 · In reply to: #62993 Hi, > Hi! > > > […] > > 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 --- Next page: https://externals.io/message/62949.md?page=2