I fail to see why checking for closures makes variable access much slower. As far as I remember, interpolated variable paths are "compiled" to use the $ctx->path() method, and it already does quite a few type checking logic already.

Checking for a closure basically would mean adding "instanceof" conditions, being instanceof an operator and as such extremely fast, I don't see why it should hurt overall performance.

best regards,
/imv

On 12/23/09 6:42 PM, Kornel Lesiński wrote:
In PHP 5.3 you can create function "on the fly":

$phptal->variable = function() {
    return "Hello World";
}


This looks like a great solution for lazy loading of data - instead of loading data up front, you just wrap it in a function that will be called in template when needed.


I've hoped to create "no-syntax" syntax for it, i.e. the code above would automatically execute function:

${variable} == "Hello World"


Although this is doable, it would make some optimisations impossible, and in turn make PHPTAL's variable access much slower (basically every time any variable is accessed, I'd have to check if it's a closure).

So I'm thinking about alternative syntax for it that would make execution of closures explicit.

${variable/invoke} or ${variable/()}? ${variable()} is an option too, but harder to implement efficiently.


Zope's TAL has nocall: modifier that makes functions returned as objects. Perhaps PHPTAL could have the opposite that makes all closures automatically executed?

${call:variable}



I've used simple variable in the examples, but I expect more complex cases to work as well:

$phptal->array = array('closure'=>function(){
    return new Object();
});

${call:array/closure/objects_property}

etc.


_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to