Re: Calling symbol table patch

At 10:56 PM 11/20/2000 +0200, Andi Gutmans wrote:

At 09:44 PM 11/20/00 +0100, Sterling Hughes wrote:

At 10:43 PM 11/20/2000 +0200, Zeev Suraski wrote:

At 22:35 20/11/2000, Andrei Zmievski wrote:

On Mon, 20 Nov 2000, Andi Gutmans wrote:

Andrei, The patch slows down the main function call opcode. I really don't

like that. How much really does it slow it down? It's just putting a pointer on a stack before the actual call and taking it off afterwards.

Well, a stack push is a considerable slowdown. How much it slows things down exactly obviously depends on your script...

Is it really that important? When did you bump into this need and why couldn't you handle it with the existing functionality? I'm not

quite clear

as to when in programming you *need* such functionality and can't

write the

code in a different (IMO better) way. But then again, you might have a very good reason because I don't know when/how this need arose.

It's impossible to implement some functionality without some sort of a patch like this. For example, I am working on a template engine, and I need to assign a variable to the template, and I got sick of typing something like this: $tpl->assign('foo', $foo); So, I wanted to speed it up and have a method that could take just names of the variables and assign them using their current values in the calling scope, like this: $tpl->batch_assign('foo', 'bar', 'color1'); But there is no way to get to calling scope: class Template {

        function batch_assign() {
                $args = func_get_args();
                foreach ($args as $var_name) {
                        /* Right here, we have no idea what $$var_name is in the
                        * function that called us. */
                }
        }

} So, that's why I wanted that patch.

I think that the Right Way to do it would actually be a function that returns the current symbol table. Such a function can be implemented without slowing down or modifying anything in the engine, and then you could write: $tpl->batch_assign('foo', 'bar', 'color1', get_active_symtable())

It's a bit more to type, no doubt, but I think it's more correct that way... Perhaps one day we'll have macros in PHP :)

Uhh, you guys turned down a patch that did just that, it was a preliminary version of the get_defined_vars() function which returns the global symbol table and the current symbol table. I had it so that you could then access and modify the variables returned (since it was merely a reference to the respective symbol tables), but (Andi I believe) requested that I not do this, so as it is it just returns the names of the different variables and not their contents.

Hmm I thought it did so :) I was against making it modifiable but it's OK to create a copy and it would solve Andrei's problem. zval_copy_ctor() would do.

For the record, I agreed with you that my original implementation was in-correct, it just seemed odd what Zeev said :) I'll modify get_defined_vars... -Sterling