From: Andy Wardley <abw@andywardley.com> Date: Tue Oct 15, 2002 07:54:18 AM US/Eastern To: Terrence Brannon <metaperl@mac.com> Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>, abw@kfs.org, Module- +Authors <module-authors@perl.org> Subject: Re: RFC Text::UberText Terrence Brannon wrote: TT2 still has issues with numerical and string equivalence checks: True. It was a difficult design decision - to keep the language simpl +e, but at the risk of making it too simple to be useful. In version 3, the parser will be much more flexible. You'll be able to configure it to identify different operators, like '==' vs 'eq' and have it generate the appropriate Perl code for the compiled template. There are many times when I like having the simplicity of just one comparison operator. I've had feedback from others, particularly those more accustomed to page design and HTML markup than programming, that agree. But also, there are times when these things matter, and you really need the ability to differentiate. So TT3 will allow you to use different grammars, even custom ones, for these different occasions. Of course, there are work-arounds in TT2. You can always define your own Perl subs to perform a particular comparison and bind them in. Sure, it's not very efficient, but it gets the job done. my $vars = { seq => sub { $_[0] eq $_[1] }, neq => sub { $_[0] == $_[1] }, }; [% IF seq(var1, var2) %] ... [% END %] [% IF neq(var1, var2) %] ... [% END %] As I stated in this thread, and as MJD stated in his docs to Text::Template, people start out trying to dumb down a power tool like + Perl and end up creating more issues than they resolve. True. But in the case of TT, it was never meant to be a dumbed down version of Perl. It's something different to Perl, for a different purpose. Leave the programming to programmers. And leave the programming to a real programming language. Absolutely. And that is why my philosophy for TT has been exactly that - leave Perl to handle the programming. TT implements a presentation language, not a programming language. It is a Domain Specific Language designed for doing presentation specific tasks. Sure, it looks a lot like a programming language and you can even use it like a programming language if you really want to, but that's not really what it's designed for. Just like you can do programming in PostScript (if you're really twisted :-) but it's not a general purpose programming language. The main argument against a DSL is that it's Yet Another Language to learn. Well yes, it is, but I don't think that's a big deal. I personally don't have any trouble switching between Perl for programmi +ng, regexes for pattern matching, SQL for database retrieval and TT for presentation. I'm of the opinion that it's better to have the right tool for the right job, even if it takes a little time to learn how to use it. Another consideration is that there are plenty of people who use simplified languages like TT, etc., who are HTML page designers who don't already know programming languages like Perl. They can pick up +a "dumbed-down" presentation language in minutes and don't have to worry + about all the nitty-gritty detail that goes with real grown-up programming languages. TT works particularly well in this respect, allowing the back-end Perl + people to build the "clever" stuff, while the front-end designers make + it all look pretty. Rather than replace Perl, TT puts emphasis on wor +king well with Perl, so that you can have the slightly better of both world +s. 1. developing a good language is very difficult. You said it! And of course, there is no one language that suits all purposes. A
In reply to Re: 'eq' vs '==' inTemplate Toolkit
by princepawn
in thread 'eq' vs '==' inTemplate Toolkit
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |