mike schreef:
> On Wed, Mar 4, 2009 at 4:01 AM, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote:
>> ..not an internals question me thinks ... redirecting to generals mailing list
>
> Actually, I do think it is somewhat internals related.
internals is about engine development. always ask on the generals list
first, you can always escalate the question if no-one there can offer
any help.
>
> I want to know from the internals/experts angle if this is a good
> function to be relying on, or if it is one of those things like the
> "@" operator which I've been told is "expensive" and to me is one of
> those things to stay away from.
>
> Now if this breaks opcode caches like APC, I will have to find another way.
>
> Also - I write procedural, not OOP. So that won't help here.
whatever. sounds like a limited way of looking at things, nonetheless
it's perfectly feasable to write the registry pattern using
functions a/some global var(s).
> Would creating functions such as
>
> output_foo_html()
> output_foo_rss()
> output_foo_json()
>
> Then depending on the output, using something like this? Would this be
> breaking opcode caches as well then?
no, the thing that breaks the opcode cache is when you declare a function
conditionally because the function declaration has to be deferred until
runtime. there are plenty of detailed posts on the internals list
about this (try searching for 'APC' will likely turn up quite alot).
> if(function_exists('output_foo_'.$format)) {
> call_user_func('output_foo_'.$format);
> } else {
> output_foo_html();
> }
you don't need call_user_func() here (which is very handy but also slow):
$func = 'output_foo_'.$format;
if (function_exists($func))
$func();
else
output_foo_html();
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
