Userfriendly (WAS: RE: String concatenation Was: Give it a whirl. ..)

[Christoph Wilhelms <Ch...@impress.com>]

Hi all!

So, from my point of view as a programmer in different programming-languages
from Fortran to Java (via COBOL, C, C++, VB, VBA) I can say that the recent
discussion pretty much annoyed me!

For me it is OBVIOUS to take "+" like in Geirs-Proposal!

Reasons: Sting concat in Fortran, Cobol, C/C++ is PIA! I know many guys who
wrote their own function-libraries just for Strings and String
concatenation! The Stream operator in C++ (<<, >>) sucks, too!

The String concatenation in java is easy and great! Why not just simply use
the Java-rules of overloading "+"!?! Ofcourse we have to interprete braces
then!

#set ($foo = "Hello")
#set ($bar1 = 1)
#set ($bar2 = 2)

#set (foo2 = $foo + ($bar1 + $bar2))

$foo2 would contain: 'Hello3'

#set (foo2 = ($foo + $bar1) + $bar2)
or
#set (foo2 = $foo + $bar1 + $bar2)

$foo2 would contain: 'Hello12'

Now this would be intuitive and usable! Don't taint yourself introducing new
operators! This would make VM not more usable!

Just my 2 cent!

Greetings,
Christoph

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Does anyone use Eclipse w/ the Velocity Tools project?

[Jeff Duska <Je...@noaa.gov>]

Hello. I'm trying to run some of the examples in the Velocity Tools 
project within in Eclipse. I curious if anyone has done this or not?

Thanks,

Jeff Duska



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Userfriendly (WAS: RE: String concatenation Was: Give it a whirl. ..)

[Daniel Dekany <dd...@freemail.hu>]

Thursday, May 2, 2002, 10:53:17 AM, Christoph Wilhelms wrote:

[snip]
> The String concatenation in java is easy and great! Why not just simply use
> the Java-rules of overloading "+"!?!

Because you can't! VTL (or what ever I should call this language) is
not strongly typed. Then, it is not necessary that something that is
good in Java language is good in VTL too because the users of this two
language are different. Then personally I disagree with the Java
language designers about this overloaded +. They are not gods so
perhaps they was not right. But again, overloaded + for a language
where you specify the type of variables (Java, C++) is much less
painful than for languages with dynamically typed variables.

[snip]
> #set ($foo = "Hello")
> #set ($bar1 = 1)
> #set ($bar2 = 2)
>
> #set (foo2 = $foo + ($bar1 + $bar2))
>
> $foo2 would contain: 'Hello3'

So it is not an runtime error then (as Geir said earlier)? IMO this
just makes the proposed + more complicated.

> #set (foo2 = ($foo + $bar1) + $bar2)
> or
> #set (foo2 = $foo + $bar1 + $bar2)
>
> $foo2 would contain: 'Hello12'
>
> Now this would be intuitive and usable!

Well... :)

> Don't taint yourself introducing new operators!
[snip]

You already did that! You have introduced a new operator: the magic
addition. Or from another viewpoint, you have introduced a new
operator: str cat, which happens to clash with art. addition as it
uses the same symbol.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Userfriendly (WAS: RE: String concatenation Was: Give it a whirl. ..)

[Daniel Dekany <dd...@freemail.hu>]

Thursday, May 2, 2002, 11:42:58 AM, Denis wrote:

[snip]
> So the idea is this:
> For any construct but macros, you can build a string by just putting one 
> after the other. E.g.
>
> #set ( greetings = "Hello " $name )

I think this is a great idea, but only if we do an incompatible change
and make ',' as the obligatory macro parameter separator. And this
probably will not happen. /-: BTW who/why voted +1 on the current
macro call syntax??? Why is it good?

> In macros, either string catenation is not available or it is done with 
> the + operator. E.g.
>
> #title( "Hello " + $name )

S-: Oh no... this is complicated and disturbing. IMO we should allow
any expression as macro parameters (well, some performance problems
are here: macro parameters are evaluated again and again every time
when they occur in the macro body) and introduce ',' as parameter
separator.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Userfriendly (WAS: RE: String concatenation Was: Give it a whirl. ..)

[Denis <ji...@respublica.fr>]

Simon,
On Thursday, May 2, 2002, at 10:07 AM, Simon Christian wrote:

> I agree wholeheartedly with this sentiment (though perhaps not with the 
> punctuation ;)

I think influential people here don't! Myself I have mixed feelings...
Christoph defines himself as a 'programmer', which is supposedly not the 
target audience of VTL. This discussion is not just nitpicking, there 
are real issues behind. Such as providing coherent syntax, making 
designers life simpler by limiting type errors in templates, etc.

My opinion is that we shouldn't try with string concatenation until 
there is an obvious answer. Geir already has a working parser that 
allows multilined strings, with embedded comments or newline escaping if 
you like, and Velocity admits all kind of things inside double 
quotes "". So the pressure for the string catenation operator is not too 
high.


Nevertheless, I will expose some new ideas as they occurred to me...
Why do we need a catenation operator? Part of the problem is that macros 
take parameters with no separator, just listed one after the other. On 
the other hand, the arithmetic + is not allowed for macro parameters.

So the idea is this:
For any construct but macros, you can build a string by just putting one 
after the other. E.g.

#set ( greetings = "Hello " $name )

In macros, either string catenation is not available or it is done with 
the + operator. E.g.

#title( "Hello " + $name )

So much for consistent syntax! But at least there would be no type 
conflicts. There would be no need to read the documentation to 
understand a template, which is a huge plus.
Try it on your templates, I think you will agree it looks quite good.

>
> Are nested braces interpreted at the moment?
>
> - simon
>
> Christoph Wilhelms wrote:
>
>> Hi all!
>> So, from my point of view as a programmer in different 
>> programming-languages
>> from Fortran to Java (via COBOL, C, C++, VB, VBA) I can say that the 
>> recent
>> discussion pretty much annoyed me!
>> For me it is OBVIOUS to take "+" like in Geirs-Proposal!
>> Reasons: Sting concat in Fortran, Cobol, C/C++ is PIA! I know many 
>> guys who
>> wrote their own function-libraries just for Strings and String
>> concatenation!

What does PIA mean?

-- Denis.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Userfriendly (WAS: RE: String concatenation Was: Give it a whirl. ..)

[Simon Christian <si...@cpd.co.uk>]

I agree wholeheartedly with this sentiment (though perhaps not with the 
punctuation ;)

Are nested braces interpreted at the moment?

- simon

Christoph Wilhelms wrote:

> Hi all!
> 
> So, from my point of view as a programmer in different programming-languages
> from Fortran to Java (via COBOL, C, C++, VB, VBA) I can say that the recent
> discussion pretty much annoyed me!
> 
> For me it is OBVIOUS to take "+" like in Geirs-Proposal!
> 
> Reasons: Sting concat in Fortran, Cobol, C/C++ is PIA! I know many guys who
> wrote their own function-libraries just for Strings and String
> concatenation! The Stream operator in C++ (<<, >>) sucks, too!
> 
> The String concatenation in java is easy and great! Why not just simply use
> the Java-rules of overloading "+"!?! Ofcourse we have to interprete braces
> then!
> 
> #set ($foo = "Hello")
> #set ($bar1 = 1)
> #set ($bar2 = 2)
> 
> #set (foo2 = $foo + ($bar1 + $bar2))
> 
> $foo2 would contain: 'Hello3'
> 
> #set (foo2 = ($foo + $bar1) + $bar2)
> or
> #set (foo2 = $foo + $bar1 + $bar2)
> 
> $foo2 would contain: 'Hello12'
> 
> Now this would be intuitive and usable! Don't taint yourself introducing new
> operators! This would make VM not more usable!
> 
> Just my 2 cent!
> 
> Greetings,
> Christoph



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>