Re: Any plans for a 100% wm syntax compatibility?

Monday, March 24, 2008, 1:29:40 PM, Demetrios Kyriakis wrote:

>
> Daniel Dekany wrote:
>> 
>>> This would not be a problem cause it's not required as the actual
>>> implementation is using Velocity, and
>>> the main reason for switch would be the fact that this engine is alive,
>>> not
>>> the extra features.
>> 
>> Despite of Velocity is not evolving (as you said), what benefit you
>> hope from switching to FM if you have to keep the old templates as-is,
>> and you don't need any extra features either? 
>> 
> I mean no other features that affect the template syntax (the one the users
> are used to), not the engine and the rest.

It pretty much sounds like creating a third template language, which
is worse than FM (and furthermore a quite much arbitrary mutilated
version of it -- whatever was possible with keeping VM compatibility),
but compatible with Velocity. So, frankly, I don't think this will
happen. You see, it would be quite an investment, and practical
usefulness aside, I don't think anyone will have that fire in the
chest to sit down and work several nights on a Velocity semi-clone.
(Not to mention to maintaining it.) OTOH, Jonathan, it would be a
quite a big slap on the face if the Velocity guys, if you implement
their own language better, and I know you like to hurt them. ;->

> What advantages? I'm not a FreeMarker expert so I can't comment, but in our
> migration draft I see things like:
> - direct advantages:
>    - a better designed API

Ugh... And that's the first point, again! No, I respect your opinion,
it's just that I used to reprove this API "design" quite regularly,
even if not loudly. So it's shocking to hear when people come and say
how nice the FreeMarker API is... I mean, for Christ's sake, what
horrific API-s they had to suffer with if this is a relief for them?
:)

>    - better error reporting
>    - less errors in the engine itself
>
> - potential advantages (due to the evolution - the project is alive):
>    - possible increase in speed
>    - possible even better error reporting
>    - possible FM level debugger.

We do have a debugger API for a long time, only nobody has written a
GUI for it, as far as I know. Attila, can you say anything about the
state of FM debugging?

>    - possible support for precompiled templates.

I don't know about such plan... Precompiled to what?

> - indirect advantages:
>    - missing of the ever increasing Apache.org bureaucracy.

Yeah. We are animals. :)

>    - issues usually don't stay unsolved for years in the tracker.
>    - patches are usually accepted (don't remain unused in the tracker)
>
>
> Daniel Dekany wrote:
>> 
>> I mean, if you just will have Velocity templates after the switching, then
>> what is changed for
>> you then?
>> 
> For me alone the simple fact that V... is practically abandoned would be a
> reason enough for a switch :).
>
> Thank you,
>
> Demetrios.
>
> -- 
> http://sourceforge.net/projects/freemat/ 
> http://freemat.sourceforge.net/

-- 
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/