Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4788
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3F86FC40.9040208@wep.net>
Date: Fri, 10 Oct 2003 14:36:48 -0400
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030929
MIME-Version: 1.0
To: Wez Furlong <wez@thebrainroom.com>
CC: internals@lists.php.net
References: <3F865B5F.9090606@wep.net> <001601c38f1b$6e5132d0$8b018552@titan> <3F86F286.5010908@wep.net> <00bf01c38f58$d0480260$8b018552@titan>
In-Reply-To: <00bf01c38f58$d0480260$8b018552@titan>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Accessing child constants from base class
From: dan@wep.net (Dan Cox)

Wez-

Wez Furlong wrote:

>>>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"));
>>>
>>>      
>>>
>>Yes. Normally, at least with most other programming languages,
>>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