Re: Re[4]: [SMARTY-DEV] More accurate compiled file names

On Mon, 31 May 2004 00:52:10 +0400 Dmitry Koteroff <spam@koteroff.ru> wrote: > There are a lot of other situations. To handle all of them, > Smarty has to be PHP. "To parse Perl you must be Perl" - Larry > Wall's words, and for PHP they are correct too: "To parse PHP you > must be PHP itself". Yep, but we're talking about Smarty templates and they are much more easier, than PHP-code. Btw, Smarty already does parse them. Anyway, I'll try to write a patch myself. I'll show you when it's ready. > What about PHP insertions in the template? > {php} > spoon(); // non-existent > {/php} This is not the case I'm talking about. PHP-code insertions in templates are evil and you should be ready to pay for that ({insert} is a special case and can be quite useful in some situations). > What about {$spoon+1}, where $spoon is undefined? Smarty does not > handle at all situations like this! Just turn E_NOTICE off, in this case it doesn't matter, of course if you know what you're doing. > No, I think it is a bad way to manually handle all errors. And you're offering to debug templates using compiled code instead.. This is not the best way we can find imho. > AD> Hmm.. how can eval() help us, if Smarty doesn't use it at all? > I know, but, if PHP's eval() would be the same as Perl's eval() > and, in addition, handles #line directive (as in Perl and C), it > would be great. But - not in this life, of course. Dreams, > dreams... I only want to say that fatal error messages must be > debugging-friendly, and we CAN do so (more or less). And I'm trying to say that Smarty just should prevent all fatal errors like mismatched tags, using non-existent methods and functions etc. -- Wbr, Antony Dovgal aka tony2001 tony2001@phpclub.net || antony@dovgal.com