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

>> I am trully shure that it is IMPOSSIBLE to handle all PHP errors >> while compiling the template. AD> Why? AD> To check if such method/function/whatever exists is quite easy imho. 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". >> And more - it is not good from >> design point of view - handle errors of one subsystem (PHP) from >> another subsystem (Smarty). AD> Why do you think so? AD> Smarty handles a lot of similar errors on parsing stage, so why not to AD> handle them all? What about PHP insertions in the template? {php} spoon(); // non-existent {/php} What about {$spoon+1}, where $spoon is undefined? Smarty does not handle at all situations like this! No, I think it is a bad way to manually handle all errors. >> Perl has a very powerful eval(). PHP's eval is much more >> primitive - it does not allow us to handle critical errors (I >> don't know why). So, the only method to improve debugging is to >> simplify detection of buggy file. 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). -- Best regards, Dmitry Koteroff.