Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Dynamic class constants »

Dynamic class constants

php.internals

Marcus Börger

21 years ago
Hello internals, this patch allows to access class constants by objects. If noone objects i'll commit it on tuesday. Example: class Test { const Foo = 'Bar'; } $obj = new Test; var_dump($obj::Foo);
-- Best regards, Marcus

Andi Gutmans

21 years ago
Hi Marcus, The patch looks fine. Before we commit I just want to make sure that we make sure we don't get bitten by this change sometime in the future. In general, the idea is that writing $obj:: will be like doing class::. It can be useful in places such as Factories and other instances. Although Marcus' patch is only for constants it would make sense to at some stage also support this notation for static properties, ala, $obj::$static_var. What's important to note that this means that $obj:: would always evaluate to class:: and not to $obj_as_string:: Personally I think this makes sense but I'd like people to think about it. So it'd mean that: $obj::$static_var access static property $static_var of $obj's class $obj::method() access static method method() of $obj's class $obj::CONST accesses constant of $obj's class. I haven't checked if this kind of implementation can be done and if there aren't any ambiguities but this is the general idea. Feedback welcome. Andi At 07:23 PM 10/3/2004 +0200, Marcus Boerger wrote:

Robert Silva

21 years ago
While this patch does add convienence at times, I don't think the benefit is great enough to blur the lines between class and object properties/methods. As was stated in the "goto" discussions, the language designers have somewhat of a responsibility to promote proper coding practices (which should also include standards to some extent). Bob Silva -----Original Message----- From: Andi Gutmans [mailto:andi@zend.com] Sent: Monday, October 04, 2004 6:03 PM To: Marcus Boerger; internals@lists.php.net Subject: Re: [PHP-DEV] Dynamic class constants Hi Marcus, The patch looks fine. Before we commit I just want to make sure that we make sure we don't get bitten by this change sometime in the future. In general, the idea is that writing $obj:: will be like doing class::. It can be useful in places such as Factories and other instances. Although Marcus' patch is only for constants it would make sense to at some stage also support this notation for static properties, ala, $obj::$static_var. What's important to note that this means that $obj:: would always evaluate to class:: and not to $obj_as_string:: Personally I think this makes sense but I'd like people to think about it. So it'd mean that: $obj::$static_var access static property $static_var of $obj's class $obj::method() access static method method() of $obj's class $obj::CONST accesses constant of $obj's class. I haven't checked if this kind of implementation can be done and if there aren't any ambiguities but this is the general idea. Feedback welcome. Andi At 07:23 PM 10/3/2004 +0200, Marcus Boerger wrote:
>Hello internals, > > this patch allows to access class constants by objects. >If noone objects i'll commit it on tuesday. > >Example: > >class Test >{ > const Foo = 'Bar'; >} > >$obj = new Test; > >var_dump($obj::Foo); > >-- >Best regards, > Marcus >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Andi Gutmans

21 years ago
Any other opinions? At 11:34 PM 10/4/2004 -0700, Robert Silva wrote:

Noah Botimer

21 years ago
Andi, I tend to agree with Bob on this one. Class vs. instance is an important distinction and, although the syntactic sugar of being able to reference a static member directly through an object and a scope resolution operator could be nice, I don't think the semantics are necessarily 100% clear. As with my other positions, I'm probably rather pedantic, but I believe that scope resolution operator should be used for ``compile-time'' notions, rather than ``runtime'' notions like referencing the class of an object, rather than inferring it from an instance. I would say that existing and additional features of the object model provide for this technique in a manner more consistent with other object systems. Specifically, the class, or base class of an object should be known if a user is to reference static members. In cases where the exact subclass is required, get_class() provides a suitable technique. The notation of $var::member should be reserved for expansion of a string in $var, naming a known class. I believe the class type hints also solidify the design patterns and relieve some possibility of being handed an object that may not conform to a given interface (exposing the required static members), limiting the application of this patch. All in all, although it would be handy, I'm not sure that deviation from other C-style languages in allowing scope resolution on instance variables really adds very much benefit beyond syntactic sugar and I fear that it may cause some undue confusion depending on variable naming (``Is that an object whose class is being referenced at runtime or a string that is being expanded and considered a class name?''). Thanks, -Noah Andi Gutmans wrote: