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
On 2012-07-13, "Eugene Leonovich" 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 instead o
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__?
Eug
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
On Wed, Apr 18, 2012 at 1:21 AM, Stas Malyshev 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(),
> get_called_class() and __NAMESP
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
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. Insi
"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
l
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
w
> 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 __CLAS
On 2012-04-17, Stas Malyshev 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 little
> chance
On Tue, Apr 17, 2012 at 6:58 PM, Stas Malyshev 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 as class nam
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 no
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, repla
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 a
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 Z
16 matches
Mail list logo
