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

From: Date: Sun, 30 May 2004 21:41:44 +0000
Subject: Re[6]: [SMARTY-DEV] More accurate compiled file names
References: 1 2 3 4 5 6  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-2337@lists.php.net to get a copy of this message
>> 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.

« previous php.smarty.dev (#2337) next »