Re[6]: More accurate compiled file names

>> 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".
AD> Yep,  but  we're  talking about Smarty templates and they are
AD> much  more  easier,  than  PHP-code. Btw, Smarty already does
AD> parse  them.  Anyway,  I'll try to write a patch myself. I'll
AD> show you when it's ready.
OK,  but are you agree that it's only another crutch (in addition
to lots of others) and no more?
 
>> What about PHP insertions in the template?
>> {php}
>> spoon(); // non-existent
>> {/php}
AD> This  is  not the case I'm talking about. PHP-code insertions
AD> in templates are evil and you should be ready to pay for that
AD> ({insert}  is  a special case and can be quite useful in some
AD> situations).
Why  should I pay for something if I can get the same on the next
street corner? I don't understand.

I  agree  that  {php}  is a bad solution. But we really can do it
more friendly for developer -

+                $_filename = $auto_source;
+                $_filename = preg_replace("{[/\\\\]}s", "^", $_filename);
+                $_filename = preg_replace("{[^a-z0-9~!_=.^-]}si", "_", $_filename);
+                $_return .= $_filename;

(Maybe with concatenating crc32() result in addition, no matter).
Why not? Can you motivate that?

>> What about {$spoon+1}, where $spoon is undefined? Smarty does not
>> handle at all situations like this!
AD> Just turn E_NOTICE off, in this case it doesn't matter, of course
AD> if you know what you're doing.
Oh, good advice - "just turn E_ERROR off and enjoy debugging hell
forever  -  it is so masochistical!". It is NOT a solution, it is
true  crutch.  I  love  E_ALL,  PHP  developers  -  too; it makes
debugging process much easier.

>> No, I think it is a bad way to manually handle all errors.
AD> And you're offering to debug templates using compiled code instead..
AD> This is not the best way we can find imho.
I  am  offering  to  make  fatal  error  more  friendly IF it has
happened  with  NO  pay for that at all. If I have choose - debug
compiled  template or tear my hairs unsuccessfully trying to find
problem file, I will choose debug compiled code. (-; If I have to
choose  pick up purse full of money wallowed the road or go past,
I will choose to pick up.

>> 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).
AD> And  I'm  trying  to  say that Smarty just should prevent all
AD> fatal errors like mismatched tags, using non-existent methods
AD> and functions etc.
It  is  impossible,  I  have  said  it before. How do you plan to
handle such situation, for example?

{math equation="($a + spoon())*20"}

Do  you  want to write complete expression parser? Maybe you want
to write PHP itself in PHP? (-;

Again:  my solution does not make our to pay something for it. It
only  simplifies debugging in critical cases, no more, no less. I
don't understand why don't you want to use it.

-- 
Best regards,
  Dmitry Koteroff.

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