Compiler re-write??

Interesting to see people suggesting that Smarty's compiler be re-written without giving reasons to support that type of re-write. I would think that something of that scope would require a truly compelling account for the need. :) Certainly there are problems here and there with Smarty's parser (for example, sometimes it produces incorrect code from correct sources). Never-the-less, it appears quite suitable for its intended application while maintaining acceptable performance levels. What I would like to see more of are plugin suites (or frameworks) that defined application types and generalized the most common type of operations for that type of application. As it is, a semi-sophisticated application built using a stock installation of Smarty is still going to require quite a bit of customized boiler-plate PHP code. Using well-planned plugin suites, otherwise custom code can be encapsulated into a grammar specific to the target user's knowledge domain. My opinion (FWIW) is that there are good reasons to support additional custom parsing types, sometimes using different parsing approaches than Smarty's. My solution has been to bolt a home-grown extendible parser onto Smarty so that they can work in tandem. This has proven very fruitful as I can now implement layered processing, meta-templates and other nifty conveniences. Would anyone be willing to provide reasons and details to justify the effort of a compiler re-write? I'm honestly very interested to understand why several have agreed that the compiler re-write is a good idea at this point. If there IS a compelling reason, then it would make a good discussion, I'm sure :). At anyrate, wouldn't it be a swell idea to re-write Smarty as a PHP module? OR to borrow from the Moto folks and rewrite the compiler to generate Apache modules instead of PHP code. THAT would be cool. :) xo boots __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/