Re[4]: 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.

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php