Re[6]: [SMARTY-DEV] More accurate compiled file names
| From: | Dmitry Koteroff | 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.