Terrence Brannon wrote:
> TT2 still has issues with numerical and string equivalence checks:
True. It was a difficult design decision - to keep the language simple,
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 programming,
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 working
well with Perl, so that you can have the slightly better of both worlds.
> 1. developing a good language is very difficult.
You said it!
And of course, there is no one language that suits all purposes.
A
