Wez Furlong wrote:
Yes. Normally, at least with most other programming languages,Performance wise, its not going to make much difference, because no matter what you are doing, to dynamically resolve the value of a constant will involve hash lookups.
The other alternative, and this is the official POV of the Zend guys IIRC, is that you can use eval() to look up the value:
$node = $doc->createElement(eval(get_class($this) . "::ElementName"));
using eval() is a major performance hit (as much as 10x slower),
so it shouldn't be used unless there is absolutely no other way.
Maybe this isn't the case with PHP?
It'll be slow no matter what you do, because you need to dynamically reference the constant value. You could also use the switch construct you already posted, or use the solution suggested by Ard; all of these are slow, particularly switch when used with a large number of string 'case's. You might actually find that the eval works out faster.
If you're really thinking of writing high performance code in PHP, you shouldn't be writing code that has 100's of class definitions ;-)
hehe. Normally, I'd agree with 100's of class definitions being a bad idea, but my particular case warrants it. Basically, I'm using PHP's new DOM features to create an API to easily build XML document fragments. It seems to make sense that each derived class be responsible for building only the bit of XML it should know about. All of these derived classes then extend an abstract class which provides the children with getXML() functionality. The code using the API then uses the objects to build a full XML document (based on a particular XML Schema). Another reason for using the derived classes is for enforcing data types, etc. at the application level, which allows me to throw informative Schema_Exception() type errors. The new dom->validate() functionality is nice, but not so useful when building an XML document yourself. AFAIK it also only works with DTDs and not XML Schemas (the XML Schema support for libxml2 is... quite lacking at this time).
Of course, I'm also using PHP's new __autoload() feature to keep performance up. :)
On a side note, when an exception is thrown from inside the __autoload() function, PHP only reports 'exception thrown in __autoload' and no other information about the exception. Is this a bug?
suppose. It just seems odd that a class can talk to it(self::)
and it's parent:: but not its child:: even though the child::
instance started the conversation in the first place :)
The engine only stores child->parent relationships, not child<->parent relationships. Think about it for a moment... can you do this kind of thing in compiled languages? Do you know why you can't? The reason is that the compiler has no way of knowing what classes are going to extend it at the time it compiles the base class.
This is why I suggested that trying to dynamically access a constant (eg: compile time!) of a child class just seems wrong.
--Wez.
I understand. For some reason, I just thought that self:: and parent:: were evaluated at runtime instead of compile time.
I believe I will just stick with a protected variable in the derived classes instead of a constant. This seems the easiest (and safe enough in my case) approach.
Thanks- Dan Cox
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
