On 12/24/09 11:50 AM, Kornel Lesiński wrote:
Yes, it probably would be negligible most of the time, but unfortunately lots of users are (unreasonably) afraid of template engine overhead and use synthetic benchmarks to compare template engines.
I think TAL attractive to users is its elegance, with that in mind, I would always advocate for the most elegant syntax even if it means loosing a few percent points in non-sense benchmarks. I do see your point though.
I think technically that's workable solution. I'm a little concerned that it would be confusing to users - closures would "sometimes" work, and sometimes cause PHPTAL to die with error like "Cannot convert Closure to string".

Also, what's your opinion about handling of __invoke() on objects that have public properties and methods? Should PHPTAL test presence of methods and properties first, or should it always invoke first?
PHP 5.3 closures are a great new feature on paper but the actual implementation feels really hacky. A closure/lambda is just syntactic sugar which gets translated to a plain object (Closure) with just an __invoke() method. There were some discussions way back to make any class wanting to use __invoke, implement a "Runnable" interface, which would have make for a bit more pleasant code, specially for introspection. Unfortunately this wasn't enforced in the implementation and any object can be a "runnable".

So taking this whole __invoke() mess into account I feel for a syntax like you first proposed, explicitly flagging a path segment as to be run.

${closure} -> $this->closure
${closure()} -> $this->closure()
${closure()/foo} -> $this->closure()->foo
${runnable/prop} -> $this->runnable->prop
${runnable()/prop} -> $this->runnable()->prop

Adding support for "()" wouldn't too difficult, I guess, since the runtime resolution is all done in Context::path(). It would also take care of your concerns, which I share, about final users not knowing at first sight if something is going to be invoked or not.

On the other hand we miss some nice refactoring ground since paths now will know what have to be invoked, so if I want to implement lazy-loading for some property I will have to either hack with __get() or modify the path expressions to add the "()".

By the way, seeing that you're working on PHP 5.3 features, I've been working on and off in a TAL engine for PHP 5.3 [1]. It's probably not working right now since I left it at the middle of quite huge refactor, perhaps you could use some of the ideas and code though for PHPTAL. I put special emphasis on using real parsers instead of regexps, using an abstract syntax tree (opcodes) allowed for a very extensible engine, even though the design is a more complex, it's even able to compile the templates to Javascript for example. The XML parser is also pretty robust (XmlReader based) and is able to tell the exact line and column when a parsing or runtime error happens, even for tales expressions.

[1] http://github.com/drslump/DrTal


PHPTAL mailing list

Reply via email to