Justin Wells [SMTP:[EMAIL PROTECTED]] wrote :
> I also don't think I would choose to represent macros the way you
> are. I also don't think much of putting ()'s around the arguments,
> there are better and cleaner solutions that don't do as much damage
> to the elegance of the syntax.
While I do not speak for the Velocity project, as I am a WM user who has
just recently begun participating on the periphery of the Velocity project,
[ they seem to tolerate me so far ;) ] the () is the general Velocity
directive syntax
#directive ( arg1 arg2 ... )
and was not created specially for VM support. VM support is now still only
a proposal (alas...). I will note the new syntax is a tremendous help, as
#macro() requires the parsing infrastructure to support a variable number of
arguements.
As a user, my personal opinion is that the #foo( arg1 ) syntax is cleaner
and clearer to code and read. I also understand that it simplifies the
parser, which is also a good thing. I believe that both tool user and tool
implementor win in this case.
To me, <input type=hidden name=blargh value='#foo($a) $b'> is clear.
What does <input type=hidden name=blargh value='#foo $a $b'> do if you are
not intimately familar with #foo ?
> In fact, I'd go so far as to say the ()'s are totally pointless. There
> isn't any circumstance in which they're needed for correct parsing of
> a directive. In order to avoid treating newline as a directive terminator
> you've had to add two ugly characters to every directive. It really
> adds absolutely nothing to the power of the language, and you have
> to admit it's ugly.
I have to respectfully disagree, mostly because I am accustomed to the same
construction in C, C++, Java et al. When I have the choice, for example as
in Perl, I choose to use (). When I don't have the choice, such as Visual
Basic, I whine... :)
Further, the ability to support a variable number of arguements to a
directive is powerful, and was extremely useful in developing the proposed
#macro() directive support.
geir
