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
regards,
/imv
_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal
