Hey Stas, et. al.,
I think I've addressed some of your concerns and completed this
feature/patch.
https://github.com/php/php-src/pull/187
More inline ...
But yes, I agree that runtime resolution only duplicates existing
behavior, so it isn't really necessary (you could argue thought that
I'm a bit confused by the class keyword in the syntax ClassName::class.
We already have the magic constant __CLASS__ which does exactly the same
class name resolving, if you refer it within the class.
So why to introduce a new keyword instead of using __CLASS__, like
ClassName::__CLASS__?
On 2012-07-13, Eugene Leonovich gen.w...@gmail.com wrote:
I'm a bit confused by the class keyword in the syntax ClassName::class.
We already have the magic constant __CLASS__ which does exactly the same
class name resolving, if you refer it within the class.
So why to introduce a new keyword
On Wed, Apr 18, 2012 at 1:21 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Well, not that you mention it, I don't see a reason why we shouldn't
add run-time resolution where necessary. For once this would allow
Runtime resolution of what? We already have get_class(),
Hi!
As already mentioned, There can't be a class constant called class,
because it is a keyword. (const class = 'Foo' is a syntax error).
It looks like class constant. So it should work like one (or, in this
case, not work since as you noticed there can not be one).
But yes, I agree that
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but
closer to what already exists for this semantic (class name as string),
don't you think ?
So, at current, is this small enough for just a pull request, or does this
deserve its own RFC?
Personnaly, I would say that an
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer,
but closer to what already exists for this semantic (class name as
string), don't you think ?
As Marco suggested, I think using __CLASS__ would be confusing to some.
__CLASS__ generally means, where you see this,
Hi!
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but
closer to what already exists for this semantic (class name as string),
don't you think ?
I like this. __CLASS__ is already being used as class name, and little
chance of colliding with some code since you're not
On Tue, Apr 17, 2012 at 6:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but
closer to what already exists for this semantic (class name as string),
don't you think ?
I like this. __CLASS__ is already being used
On 2012-04-17, Stas Malyshev smalys...@sugarcrm.com wrote:
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but
closer to what already exists for this semantic (class name as string),
don't you think ?
I like this. __CLASS__ is already being used as class name, and
From the collisions point of view `class` and `__CLASS__` are equally
safe.
Imho ClassName::class reads nicer and also looks similar to the
similar ClassName.class syntax in Java.
The current __CLASS__ could then be written self::class. Looks more
namespace/object oriented, where __CLASS__
How would static::class behave ? is it handled by the current patch?
Maybe the test case could be extended to reflect this, and also for
self::class?
Fantastic question. I am unsure how to handle this. Currently, it will
simply resolve those names against the rules (I am sure this is the
class won't collide anyways, as it's already a keyword, and you can't use it
in your constant or function names. __CLASS__ has bad connotations for me, as it
resolves to the declaring class normally, not the class invoked.
I tend to agree. __CLASS__ to me belongs to the family of constants
Hi!
Fantastic question. I am unsure how to handle this. Currently, it will
simply resolve those names against the rules (I am sure this is the
wrong behavior.) So,
namespace Foo\Bar { var_dump(self::class); }
This should produce an error outside of class context, I think. Inside
Hi!
I tend to agree. __CLASS__ to me belongs to the family of constants
like __DIR__ and __FILE__ where they are meant to be evaluated in-place
and are simply a substitution for something completely static.
But that's exactly what Foo::class is - completely static constant.
In my mind,
So, at current, is this small enough for just a pull request, or does
this deserve its own RFC?
-ralph
On 4/14/12 2:50 PM, Ralph Schindler wrote:
Hi all,
There are many different use cases were in code we expect classes names
as arguments to functions as fully qualified names. We do this in
16 matches
Mail list logo
