Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

Daniel Dekany
This is a devel list topic so let's continue this thread there... and
it should have been started there as well.

So, the parent-child stuff you have done... great! This is exactly
what I though by parent-children communication (without utilizing the
"scope" feature of course, as that wasn't exist back then). Although
one could reason that it's a rather primitive form of parent-child
communication, which limits its possible usages, I guess that for
FreeMarker (which meant to be a simple language with script language
spirit) we shouldn't introduce a more serious implementation. (That I
question if this take-it-easy/do-everything-runtime script language
approach of FM is optimal for an MVC template language is another
thing... I think FreeMarker should just remain true for that
philosophy at this point of history.)

BTW, with 2.4, do we deprecate #local in favor of #scoped? What is the
relation of the two directives? And what about #global? What about the
relation of #global and #set? (I know, I could try, read the archive,
etc, but I believe it's better if others hear the answers as well.)

Monday, April 30, 2007, 4:14:03 PM, Jonathan Revusky wrote:

> I just added a new built-in called ?scope that applies to a macro.
> Basically, it returns the local scope (as a hash basically) of a macro
> higher up in the call stack.
>
> Here is the test case I just checked in:
> --------------------------------------
> <#set color = "red">
>
> <#macro tr color="blue">
>     ${color} <#-- blue when unqualified, since this was passed in as a
local param -->>

>
>     <#set color = "green"> <#-- only sets the local var, of course -->
>
>     ${.namespace["color"]} <#-- still red in the enclosing namespace -->
>     ----
>     <@td />
>
>     ----
>     ${color} <#-- yellow, since it was changed in the td macro we called -->
> </#macro>
>
> <#macro td>
>     ${color} <#-- unqualifed, we get the color var from the namespace,
red -->>
>     ${tr?scope["color"]} <#-- now we get the upvalue "color" from the tr
scope, green -->>
>     <#set color = "yellow" in tr?scope> <#-- We can set it in the scope,
> though it would rarely be good practice. -->
> </#macro>
>
> <@tr/>
> --
> ${color} <#-- red, of course, since it was never changed at the
namespace level -->>

> ------------------------------------------
>
> The output of the testcase is:
>
>     blue
>     red
>     ----
>     red
>     green
>     ----
>     yellow
> --
> red
>
>
> Any thoughts?
>
> JR

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

revusky
On 4/30/07, Daniel Dekany <[hidden email]> wrote:
> This is a devel list topic so let's continue this thread there... and
> it should have been started there as well.
>
> So, the parent-child stuff you have done... great! This is exactly
> what I though by parent-children communication (without utilizing the
> "scope" feature of course, as that wasn't exist back then). Although
> one could reason that it's a rather primitive form of parent-child
> communication, which limits its possible usages,

If there is a need for something more than this, it can be extended,
but I think this is likely to be enough. I forgot to mention that,
beside the ?scope built-in which walks up the call stack and returns
the local context of the macro in question (it returns null if it
finds nothing) there is also a  .scope built-in variable that provides
the hash of the current local scope. So it can be assigned and live
beyond the scope in which it was created in fact.

The scope type variable is a hash but it also supports a ?resolve
built-in. The difference between scope["foo"] and scope?resolve("foo")
is that the latter, if it doesn't find a variable foo in its own
scope, continues with the typical variable resolution rules -- going
to the namespace it is contained in and so on up to global variables
and the data model.

> I guess that for
> FreeMarker (which meant to be a simple language with script language
> spirit) we shouldn't introduce a more serious implementation. (That I
> question if this take-it-easy/do-everything-runtime script language
> approach of FM is optimal for an MVC template language is another
> thing... I think FreeMarker should just remain true for that
> philosophy at this point of history.)

well, it seems that this was necessary to support fully the writing of
complex macro libraries. The up-values thing is actually a language
feature that even regular programming languages do not typically have.
So, you know, even if it doesn't take into account some (probably very
rare) corner cases, this is all quite insanely powerful....

>
> BTW, with 2.4, do we deprecate #local in favor of #scoped? What is the
> relation of the two directives? And what about #global? What about the
> relation of #global and #set? (I know, I could try, read the archive,
> etc, but I believe it's better if others hear the answers as well.)

The intention (my intention) is for <#set..> + <#scoped...> to
supersede all the previously existing assignment directives, i.e.
local/assign/global. Basically <#set ...> is a synonym of <#assign..>
except that if the variable has been declared to be scoped in that
block, then it is like <#local...>, with the one big difference that
it is more flexible because scoped/set works in any block, not just
macros.

It actually completely supersedes the use of local, and I am
considering writing a little conversion utility that simply converts
all the older assignment stuff to set/scoped.

As for <#global....> that should only very rarely be used, it would
seem to be bad practice. There should rarely be a need to assign a
variable that is more widely visible than the namespace level. So,
since it's rare to use it, it seems okay to have that be:

<#set foo = "bar" in .globals>

which is more verbose.  Of course, we will probably never remove
local/assign/global, so <#global foo = "bar"> will continue to work
indefinitely anyway.

If there exists a foo variable in the local scope and also in the
namespace scope, then you would need to write:

<#set foo = "bar" in .namespace>

in order to set the variable in the namespace instead of the local
scope. (Though again, the shorter <#assign foo = "bar"> will continue
to work indefinitely.) However, again, I think the need for this is
rare. If there is a foo variable in the local scope, that is what you
want to set when you set the foo variable typically. THe other thing
is rare enough that it seems desirable to have to state very clearly
your intention by saying "in .namespace" or "in .globals", if you see
what I mean.

in most typical scenarios, it seems that an unqualified <#set...> will
do what people want and would expect. And this leads to an overall
simplification of FTL as compared to the local/assign/global business.

Anyway, look at the test-scopes testcase and you see what is going on.

Oh, I'd add that set/scoped is less error-prone, because if you just
use set everywhere, you don't have the problem of:

<#macro someMacro foo="default">
  ...
  ....
  <#assign foo = "something">

  ....
</#macro>

In the above case, the intention might usually just be to assign to
the foo variable that exists in the macro, so it should be <#set foo =
"something"> but somebody could write <#assign...> instead of set, and
that would create a new variable called foo at the namespace level,
and doesn't change the existing one at the macro level. All that is
quite screwy really.

If we encourage people to use <#set...> we avoid all that. And,
anyway, I anticipate at some point having a conversion utility that
simply converts templates to the new preferred set/scoped syntax.

JR


> Monday, April 30, 2007, 4:14:03 PM, Jonathan Revusky wrote:
>
> > I just added a new built-in called ?scope that applies to a macro.
> > Basically, it returns the local scope (as a hash basically) of a macro
> > higher up in the call stack.
> >
> > Here is the test case I just checked in:
> > --------------------------------------
> > <#set color = "red">
> >
> > <#macro tr color="blue">
> >     ${color} <#-- blue when unqualified, since this was passed in as a
> local param -->>
> >
> >     <#set color = "green"> <#-- only sets the local var, of course -->
> >
> >     ${.namespace["color"]} <#-- still red in the enclosing namespace -->
> >     ----
> >     <@td />
> >
> >     ----
> >     ${color} <#-- yellow, since it was changed in the td macro we called -->
> > </#macro>
> >
> > <#macro td>
> >     ${color} <#-- unqualifed, we get the color var from the namespace,
> red -->>
> >     ${tr?scope["color"]} <#-- now we get the upvalue "color" from the tr
> scope, green -->>
> >     <#set color = "yellow" in tr?scope> <#-- We can set it in the scope,
> > though it would rarely be good practice. -->
> > </#macro>
> >
> > <@tr/>
> > --
> > ${color} <#-- red, of course, since it was never changed at the
> namespace level -->>
> > ------------------------------------------
> >
> > The output of the testcase is:
> >
> >     blue
> >     red
> >     ----
> >     red
> >     green
> >     ----
> >     yellow
> > --
> > red
> >
> >
> > Any thoughts?
> >
> > JR
>
> --
> Best regards,
>  Daniel Dekany
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

Daniel Dekany
Monday, April 30, 2007, 6:47:40 PM, Jonathan Revusky wrote:

> On 4/30/07, Daniel Dekany <[hidden email]> wrote:
>> This is a devel list topic so let's continue this thread there... and
>> it should have been started there as well.
>>
>> So, the parent-child stuff you have done... great! This is exactly
>> what I though by parent-children communication (without utilizing the
>> "scope" feature of course, as that wasn't exist back then). Although
>> one could reason that it's a rather primitive form of parent-child
>> communication, which limits its possible usages,
>
> If there is a need for something more than this, it can be extended,
> but I think this is likely to be enough. I forgot to mention that,
> beside the ?scope built-in which walks up the call stack and returns
> the local context of the macro in question (it returns null if it
> finds nothing) there is also a  .scope built-in variable that provides
> the hash of the current local scope. So it can be assigned and live
> beyond the scope in which it was created in fact.
>
> The scope type variable is a hash but it also supports a ?resolve
> built-in. The difference between scope["foo"] and scope?resolve("foo")
> is that the latter, if it doesn't find a variable foo in its own
> scope, continues with the typical variable resolution rules -- going
> to the namespace it is contained in and so on up to global variables
> and the data model.
>
>> I guess that for
>> FreeMarker (which meant to be a simple language with script language
>> spirit) we shouldn't introduce a more serious implementation. (That I
>> question if this take-it-easy/do-everything-runtime script language
>> approach of FM is optimal for an MVC template language is another
>> thing... I think FreeMarker should just remain true for that
>> philosophy at this point of history.)
>
> well, it seems that this was necessary to support fully the writing of
> complex macro libraries. The up-values thing is actually a language
> feature that even regular programming languages do not typically have.
> So, you know, even if it doesn't take into account some (probably very
> rare) corner cases, this is all quite insanely powerful....

Please, please... "insanely". Don't make me laugh. Nor get me wrong.
It's just like someone creates a flint stone knife, which is
respectable in the world of wooden "knifes", but yet it makes you
laugh if it is called instantly powerful. If you know that knifes
should be made from steel, that is (although it is a huge investment
to implement that, no wonder nobody did it... the mining, furnace,
etc.). Really, for any language that is about defining procedures that
are often meant to be nested into each other like elements in XML, it
is a basic thing. Not something that should take several years to
realize, if somebody cares about the topic, right? ;) And for those
who wonder why is this implementation not a steel knife, well... the
real thing behind the whole parent-child communication stuff is that
each macro that can have nested content creates a context for all the
stuff that is inside its nested content. And then of course, the
"type" of this context (what fields do you have in it, what methods do
you have in it, etc) is, in the generic case, independent from the
macro that creates it. I.e. multiple macros could possibly create the
same kind of context. Not so in FreeMarker. Furthermore in FreeMarker
this context that the macro creates is the set of the local
(traditionally means: private, implementation detail) variables of the
macro, which could be seen as scary. Now surely this last can be a
practical problem only for really complex and long-lived (i.e.
maintained) systems, which is not what the Java Language was well
designed for either, so whatever. People build huge system with all of
these toy stuff, like Java, because there is no better, so they could
be happy with FM as well. Well not to mention, that implementing
something like template engine that really takes itself serious, would
be a very *very* time consuming and really a damn hard task (I can
tell as I experience it on myself... bastard template languages has
some extreme demands that you don't face with in the case of
conventional languages, and they can really spoil your day), so I'm
happy that you (and Attila, and a little bit me as well) have done
this at least. So don't get me wrong... I'm just a bit perfectionist.

>> BTW, with 2.4, do we deprecate #local in favor of #scoped? What is the
>> relation of the two directives? And what about #global? What about the
>> relation of #global and #set? (I know, I could try, read the archive,
>> etc, but I believe it's better if others hear the answers as well.)
>
> The intention (my intention) is for <#set..> + <#scoped...> to
> supersede all the previously existing assignment directives, i.e.
> local/assign/global. Basically <#set ...> is a synonym of <#assign..>
> except that if the variable has been declared to be scoped in that
> block, then it is like <#local...>, with the one big difference that
> it is more flexible because scoped/set works in any block, not just
> macros.

Fine.

> It actually completely supersedes the use of local, and I am
> considering writing a little conversion utility that simply converts
> all the older assignment stuff to set/scoped.
>
> As for <#global....> that should only very rarely be used, it would
> seem to be bad practice. There should rarely be a need to assign a
> variable that is more widely visible than the namespace level. So,
> since it's rare to use it, it seems okay to have that be:
>
> <#set foo = "bar" in .globals>
>
> which is more verbose.  Of course, we will probably never remove
> local/assign/global, so <#global foo = "bar"> will continue to work
> indefinitely anyway.

Then I will move #global to the deprecated directives section of the
Manual. I'm happy to see these stupid things (especially #assign)
gone, really. The user will be too, I'm sure...

> If there exists a foo variable in the local scope and also in the
> namespace scope, then you would need to write:
>
> <#set foo = "bar" in .namespace>

Which is consistent as you had to apply similar trick anyway if you
want to read the "foo" variable.

BTW, this .namespace sound me like a misnomer. The .global and even
the local scope are namespaces as well. Shouldn't it be .template or
something?

> in order to set the variable in the namespace instead of the local
> scope. (Though again, the shorter <#assign foo = "bar"> will continue
> to work indefinitely.) However, again, I think the need for this is
> rare. If there is a foo variable in the local scope, that is what you
> want to set when you set the foo variable typically. THe other thing
> is rare enough that it seems desirable to have to state very clearly
> your intention by saying "in .namespace" or "in .globals", if you see
> what I mean.
>
> in most typical scenarios, it seems that an unqualified <#set...> will
> do what people want and would expect. And this leads to an overall
> simplification of FTL as compared to the local/assign/global business.
>
> Anyway, look at the test-scopes testcase and you see what is going on.
>
> Oh, I'd add that set/scoped is less error-prone, because if you just
> use set everywhere, you don't have the problem of:
>
> <#macro someMacro foo="default">
>   ...
>   ....
>   <#assign foo = "something">
>
>   ....
> </#macro>
>
> In the above case, the intention might usually just be to assign to
> the foo variable that exists in the macro, so it should be <#set foo =
"something">> but somebody could write <#assign...> instead of set, and
> that would create a new variable called foo at the namespace level,
> and doesn't change the existing one at the macro level. All that is
> quite screwy really.

Yes. And seeing <#assign ...> is also quite shocking for newcomers. My
first reaction was something like "Holly shit. Why not
<#wantThisVariableToBeEqualWith ...> then? Do these guys know the
English world 'set', that also happens to be used almost everywhere in
IT for this thing?" And of course it was not you who invented
"assign", but newcomers just don't know that... :)

> If we encourage people to use <#set...> we avoid all that. And,
> anyway, I anticipate at some point having a conversion utility that
> simply converts templates to the new preferred set/scoped syntax.

And maybe upgrade US Cavalier... and rename it (out of curiosity, why
is that called like that?). Well if , and I hope that, you will again
feel like hacking stuff. That can be quite fun... better than ******,
as I used to encourage some people. :) Bad to find myself burnt out in
this field sometimes... /-: oh well.

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

revusky
On 4/30/07, Daniel Dekany <[hidden email]> wrote:
> Monday, April 30, 2007, 6:47:40 PM, Jonathan Revusky wrote:

> > well, it seems that this was necessary to support fully the writing of
> > complex macro libraries. The up-values thing is actually a language
> > feature that even regular programming languages do not typically have.
> > So, you know, even if it doesn't take into account some (probably very
> > rare) corner cases, this is all quite insanely powerful....
>
> Please, please... "insanely". Don't make me laugh. Nor get me wrong.
> It's just like someone creates a flint stone knife, which is
> respectable in the world of wooden "knifes", but yet it makes you
> laugh if it is called instantly powerful. If you know that knifes
> should be made from steel, that is (although it is a huge investment
> to implement that, no wonder nobody did it... the mining, furnace,
> etc.). Really, for any language that is about defining procedures that
> are often meant to be nested into each other like elements in XML, it
> is a basic thing. Not something that should take several years to
> realize, if somebody cares about the topic, right? ;) And for those
> who wonder why is this implementation not a steel knife, well... the
> real thing behind the whole parent-child communication stuff is that
> each macro that can have nested content creates a context for all the
> stuff that is inside its nested content. And then of course, the
> "type" of this context (what fields do you have in it, what methods do
> you have in it, etc) is, in the generic case, independent from the
> macro that creates it. I.e. multiple macros could possibly create the
> same kind of context. Not so in FreeMarker. Furthermore in FreeMarker
> this context that the macro creates is the set of the local
> (traditionally means: private, implementation detail) variables of the
> macro, which could be seen as scary.

Yes, it could make one uneasy. It probably does have some significant
potential for evil.

But surely we are not about to introduce public/private/protected
visibility declarations, are we... and the need to sometimes get at
things in the scope of a macro higher up in the call stack looks
pretty real.

Within the range of what is reasonable for a language like this, this
may be pretty much okay. It is stuff that only a power user doing
complex macro libraries would be using.

> >> BTW, with 2.4, do we deprecate #local in favor of #scoped? What is the
> >> relation of the two directives? And what about #global? What about the
> >> relation of #global and #set? (I know, I could try, read the archive,
> >> etc, but I believe it's better if others hear the answers as well.)
> >
> > The intention (my intention) is for <#set..> + <#scoped...> to
> > supersede all the previously existing assignment directives, i.e.
> > local/assign/global. Basically <#set ...> is a synonym of <#assign..>
> > except that if the variable has been declared to be scoped in that
> > block, then it is like <#local...>, with the one big difference that
> > it is more flexible because scoped/set works in any block, not just
> > macros.
>
> Fine.

I'm glad you agree. Just for the gallery, all previous syntax will
continue to work. This won't break existing templates. It's just that
the newer syntax will now be preferred, in docs, examples, and
whatnot.

>
> > It actually completely supersedes the use of local, and I am
> > considering writing a little conversion utility that simply converts
> > all the older assignment stuff to set/scoped.
> >
> > As for <#global....> that should only very rarely be used, it would
> > seem to be bad practice. There should rarely be a need to assign a
> > variable that is more widely visible than the namespace level. So,
> > since it's rare to use it, it seems okay to have that be:
> >
> > <#set foo = "bar" in .globals>
> >
> > which is more verbose.  Of course, we will probably never remove
> > local/assign/global, so <#global foo = "bar"> will continue to work
> > indefinitely anyway.
>
> Then I will move #global to the deprecated directives section of the
> Manual. I'm happy to see these stupid things (especially #assign)
> gone, really. The user will be too, I'm sure...

I think actually all 3 of them could be deprecated, global, assign,
and local. The set+scoped stuff covers all the cases those things
cover, and a bit more, since you can declare scoped variables in any
template block, like the body of a loop, or an if or whatever.

<#list items as item>
   <#scoped x, y> <#-- Note that item, item_has_next and item_count
are also scoped variables here implicitly.-->

   And now any set directive involving x and y is automatically local
to the list block.

</#list>

>
> > If there exists a foo variable in the local scope and also in the
> > namespace scope, then you would need to write:
> >
> > <#set foo = "bar" in .namespace>
>
> Which is consistent as you had to apply similar trick anyway if you
> want to read the "foo" variable.

Generally, if there is a foo variable in a macro, that is what you
want to read and write when you refer to foo in there. That there is
occasionally an outer foo defined in the namespace and you need a
disposition to get at it, this is necessary for language completeness,
but it should not often be used, I think.

>
> BTW, this .namespace sound me like a misnomer. The .global and even
> the local scope are namespaces as well. Shouldn't it be .template or
> something

Not really, since it could be a library namespace. There is also a
.main which is the "main" template namespace, something one might
occasionally need to get at. I think I thought about this and we may
have discussed it and, you know, if the alternative is
.current_namespace, that's just too verbose, you see, so finally it
was .namespace. I've got .scope as well for the innermost scope, but
that maybe should be .local_scope or something, but it gets maybe too
long to write these things.


>
> > in order to set the variable in the namespace instead of the local
> > scope. (Though again, the shorter <#assign foo = "bar"> will continue
> > to work indefinitely.) However, again, I think the need for this is
> > rare. If there is a foo variable in the local scope, that is what you
> > want to set when you set the foo variable typically. THe other thing
> > is rare enough that it seems desirable to have to state very clearly
> > your intention by saying "in .namespace" or "in .globals", if you see
> > what I mean.
> >
> > in most typical scenarios, it seems that an unqualified <#set...> will
> > do what people want and would expect. And this leads to an overall
> > simplification of FTL as compared to the local/assign/global business.
> >
> > Anyway, look at the test-scopes testcase and you see what is going on.
> >
> > Oh, I'd add that set/scoped is less error-prone, because if you just
> > use set everywhere, you don't have the problem of:
> >
> > <#macro someMacro foo="default">
> >   ...
> >   ....
> >   <#assign foo = "something">
> >
> >   ....
> > </#macro>
> >
> > In the above case, the intention might usually just be to assign to
> > the foo variable that exists in the macro, so it should be <#set foo =
> "something">> but somebody could write <#assign...> instead of set, and
> > that would create a new variable called foo at the namespace level,
> > and doesn't change the existing one at the macro level. All that is
> > quite screwy really.
>
> Yes. And seeing <#assign ...> is also quite shocking for newcomers. My
> first reaction was something like "Holly shit. Why not
> <#wantThisVariableToBeEqualWith ...> then? Do these guys know the
> English world 'set', that also happens to be used almost everywhere in
> IT for this thing?" And of course it was not you who invented
> "assign", but newcomers just don't know that... :)

Yes, it's also long. (It eliminates another very slight (really,
totally trivial) advantage that Velocity has over us. :-))

>
> > If we encourage people to use <#set...> we avoid all that. And,
> > anyway, I anticipate at some point having a conversion utility that
> > simply converts templates to the new preferred set/scoped syntax.
>
> And maybe upgrade US Cavalier... and rename it (out of curiosity, why
> is that called like that?).

It's U.S. Cavalry, and the origin is a little joke. (Killing apaches...)

The joke is now old, of course, so if you have a better name (maybe
with a newer little joke...)


> Well if , and I hope that, you will again
> feel like hacking stuff. That can be quite fun... better than ******,
> as I used to encourage some people. :) Bad to find myself burnt out in
> this field sometimes... /-: oh well.

I think we're going to see some pretty significant forward movement
now again. I really do. There's another idea I am going to float
fairly soon that I think could be quite interesting.

I actually think maybe this next release cycle should be 3.0.

Jonathan

>
> --
> Best regards,
>  Daniel Dekany
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

Daniel Dekany
Monday, April 30, 2007, 10:22:16 PM, Jonathan Revusky wrote:

> On 4/30/07, Daniel Dekany <[hidden email]> wrote:
[snip]
>> (traditionally means: private, implementation detail) variables of the
>> macro, which could be seen as scary.
>
> Yes, it could make one uneasy. It probably does have some significant
> potential for evil.
>
> But surely we are not about to introduce public/private/protected
> visibility declarations, are we...

Yes, we won't for something like FreeMarker... it just wouldn't fit
its approach well. OTOH private/public has little to do with this
issue now (that we (certainly) will not address). It is that the
context created by a macro call has in principle nothing to do with
its local variables. So they naturally wouldn't mix, no mater if we
have private/public. But, anyway, as I said, certainly better if we
just leave in this primitive state. Easier to learn, minimal amount of
new terms introduced... and, well, limited usability as the shadowy
side.

> and the need to sometimes get at things in the scope of a macro
> higher up in the call stack looks pretty real.
>
> Within the range of what is reasonable for a language like this, this
> may be pretty much okay. It is stuff that only a power user doing
> complex macro libraries would be using.
>
>> >> BTW, with 2.4, do we deprecate #local in favor of #scoped? What is the
>> >> relation of the two directives? And what about #global? What about the
>> >> relation of #global and #set? (I know, I could try, read the archive,
>> >> etc, but I believe it's better if others hear the answers as well.)
>> >
>> > The intention (my intention) is for <#set..> + <#scoped...> to
>> > supersede all the previously existing assignment directives, i.e.
>> > local/assign/global. Basically <#set ...> is a synonym of <#assign..>
>> > except that if the variable has been declared to be scoped in that
>> > block, then it is like <#local...>, with the one big difference that
>> > it is more flexible because scoped/set works in any block, not just
>> > macros.
>>
>> Fine.
>
> I'm glad you agree. Just for the gallery, all previous syntax will
> continue to work. This won't break existing templates. It's just that
> the newer syntax will now be preferred, in docs, examples, and
> whatnot.
>
>>
>> > It actually completely supersedes the use of local, and I am
>> > considering writing a little conversion utility that simply converts
>> > all the older assignment stuff to set/scoped.
>> >
>> > As for <#global....> that should only very rarely be used, it would
>> > seem to be bad practice. There should rarely be a need to assign a
>> > variable that is more widely visible than the namespace level. So,
>> > since it's rare to use it, it seems okay to have that be:
>> >
>> > <#set foo = "bar" in .globals>
>> >
>> > which is more verbose.  Of course, we will probably never remove
>> > local/assign/global, so <#global foo = "bar"> will continue to work
>> > indefinitely anyway.
>>
>> Then I will move #global to the deprecated directives section of the
>> Manual. I'm happy to see these stupid things (especially #assign)
>> gone, really. The user will be too, I'm sure...
>
> I think actually all 3 of them could be deprecated, global, assign,
> and local.

Yes, I meant that too. We have a "Deprecated FTL constructs" section
in the Reference, they will be all move there.

> The set+scoped stuff covers all the cases those things
> cover, and a bit more, since you can declare scoped variables in any
> template block, like the body of a loop, or an if or whatever.
>
> <#list items as item>
>    <#scoped x, y> <#-- Note that item, item_has_next and item_count
> are also scoped variables here implicitly.-->
>
>    And now any set directive involving x and y is automatically local
> to the list block.
>
> </#list>

I wonder, however, if disallowing scoped variables hiding each other
is a good idea. Currently if I do this:

  <#if true>
    <#scoped x = 2>
    <#if true>
      <#scoped x = 3>
    </#if>
  </#if>

then I get a parsing exception, saying "Scoped variable x is already
defined at this point". If I had to design a template language right
now, while I'm no 100% sure about it, I would rather allow it. I see
that it can cause confusion, but... a template is not like a Java
method. It used to be much longer, and used to have much deeper
nesting, and used to contain many little "islands", the nearly
independent bits the page is from. So, in a such little island I want
to say that I need here a local variable called x, and I don't want to
afraid about all the mess this island is in the middle of. But with
the current rules I have to. It surely depends on what kind of
templates you have in a project, but maybe for many it will be more a
burden than a help. Anyway, if we are talking about unintended
variable hiding, the hiding of data model variables and the hiding of
.namespace (top-level) variables, which are all allowed, are more a
risk. So it is inconsistent that we don't allow scoped variables
hiding each-other, if we allow hiding data model variables and
top-level variables. It's not what the users expects, I believe.

>>
>> > If there exists a foo variable in the local scope and also in the
>> > namespace scope, then you would need to write:
>> >
>> > <#set foo = "bar" in .namespace>
>>
>> Which is consistent as you had to apply similar trick anyway if you
>> want to read the "foo" variable.
>
> Generally, if there is a foo variable in a macro, that is what you
> want to read and write when you refer to foo in there. That there is
> occasionally an outer foo defined in the namespace and you need a
> disposition to get at it, this is necessary for language completeness,
> but it should not often be used, I think.
>
>>
>> BTW, this .namespace sound me like a misnomer. The .global and even
>> the local scope are namespaces as well. Shouldn't it be .template or
>> something
>
> Not really, since it could be a library namespace.

FreeMarker has only one kind of file-like unit, that we call
templates. It doesn't have the concept of libraries, it only have
templates. Even if in practice some templates are used as a collection
of macros, without any useful "main" code.

> There is also a
> .main which is the "main" template namespace, something one might
> occasionally need to get at.

That's just the .namespace of the initially called template, if I
remember well.

> I think I thought about this and we may
> have discussed it and, you know, if the alternative is
> .current_namespace, that's just too verbose, you see, so finally it
> was .namespace.

Well I have no idea how it went through... such a misnomer.

> I've got .scope as well for the innermost scope, but
> that maybe should be .local_scope or something, but it gets maybe too
> long to write these things.

"scope" is a pretty bad name as well, but "local" is already used.

OK, so, what names should we use... I think .main, .template (means
the template we are in) and... what do we need .scope for?

>> > in order to set the variable in the namespace instead of the local
>> > scope. (Though again, the shorter <#assign foo = "bar"> will continue
>> > to work indefinitely.) However, again, I think the need for this is
>> > rare. If there is a foo variable in the local scope, that is what you
>> > want to set when you set the foo variable typically. THe other thing
>> > is rare enough that it seems desirable to have to state very clearly
>> > your intention by saying "in .namespace" or "in .globals", if you see
>> > what I mean.
>> >
>> > in most typical scenarios, it seems that an unqualified <#set...> will
>> > do what people want and would expect. And this leads to an overall
>> > simplification of FTL as compared to the local/assign/global business.
>> >
>> > Anyway, look at the test-scopes testcase and you see what is going on.
>> >
>> > Oh, I'd add that set/scoped is less error-prone, because if you just
>> > use set everywhere, you don't have the problem of:
>> >
>> > <#macro someMacro foo="default">
>> >   ...
>> >   ....
>> >   <#assign foo = "something">
>> >
>> >   ....
>> > </#macro>
>> >
>> > In the above case, the intention might usually just be to assign to
>> > the foo variable that exists in the macro, so it should be <#set foo =
>> "something">> but somebody could write <#assign...> instead of set, and
>> > that would create a new variable called foo at the namespace level,
>> > and doesn't change the existing one at the macro level. All that is
>> > quite screwy really.
>>
>> Yes. And seeing <#assign ...> is also quite shocking for newcomers. My
>> first reaction was something like "Holly shit. Why not
>> <#wantThisVariableToBeEqualWith ...> then? Do these guys know the
>> English world 'set', that also happens to be used almost everywhere in
>> IT for this thing?" And of course it was not you who invented
>> "assign", but newcomers just don't know that... :)
>
> Yes, it's also long. (It eliminates another very slight (really,
> totally trivial) advantage that Velocity has over us. :-))

Oh yes, indeed. Now we don't have to shun from the world anymore. :)

>>
>> > If we encourage people to use <#set...> we avoid all that. And,
>> > anyway, I anticipate at some point having a conversion utility that
>> > simply converts templates to the new preferred set/scoped syntax.
>>
>> And maybe upgrade US Cavalier... and rename it (out of curiosity, why
>> is that called like that?).
>
> It's U.S. Cavalry, and the origin is a little joke. (Killing apaches...)

Ahhh... stupid me. Wasn't Spain also heavily involved in these things?
Can't be a coincidence... :)

> The joke is now old, of course, so if you have a better name (maybe
> with a newer little joke...)

vm2ftl, Velocity Converter, whatever... something understandable.

>> Well if , and I hope that, you will again
>> feel like hacking stuff. That can be quite fun... better than ******,
>> as I used to encourage some people. :) Bad to find myself burnt out in
>> this field sometimes... /-: oh well.
>
> I think we're going to see some pretty significant forward movement
> now again. I really do. There's another idea I am going to float
> fairly soon that I think could be quite interesting.
>
> I actually think maybe this next release cycle should be 3.0.

Aham... what changes do you plan? Something brutal and revolutionary
maybe?

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

revusky
On 5/1/07, Daniel Dekany <[hidden email]> wrote:

> Monday, April 30, 2007, 10:22:16 PM, Jonathan Revusky wrote:
>
> > I think actually all 3 of them could be deprecated, global, assign,
> > and local.
>
> Yes, I meant that too. We have a "Deprecated FTL constructs" section
> in the Reference, they will be all move there.
>
> > The set+scoped stuff covers all the cases those things
> > cover, and a bit more, since you can declare scoped variables in any
> > template block, like the body of a loop, or an if or whatever.
> >
> > <#list items as item>
> >    <#scoped x, y> <#-- Note that item, item_has_next and item_count
> > are also scoped variables here implicitly.-->
> >
> >    And now any set directive involving x and y is automatically local
> > to the list block.
> >
> > </#list>
>
> I wonder, however, if disallowing scoped variables hiding each other
> is a good idea. Currently if I do this:
>
>   <#if true>
>     <#scoped x = 2>
>     <#if true>
>       <#scoped x = 3>
>     </#if>
>   </#if>
>
> then I get a parsing exception, saying "Scoped variable x is already
> defined at this point". If I had to design a template language right
> now, while I'm no 100% sure about it, I would rather allow it. I see
> that it can cause confusion, but... a template is not like a Java
> method.

I wasn't so absolutely sure about this really. I was experimenting
with different approaches. I realized that we were allowing something
that even java didn't allow, and I was thinking maybe it should not be
permitted.

Actually, here is a little secret. In f.t.c.a.TemplateElement, you can
see that there is a

static final boolean  LIMIT_NESTING=true;

If you change that to false and rebuild the project, then the
limitation is gone. Now, I don't intend to go the weak-kneed Velocity
approach of simply making this a configuration switch. At some point,
we have to decide whether it is desirable to limit the
nesting/redefinition of variables like this or not.

But currently, in the pre-pre-pre-release state of things, it is a
changeable option via the thing above.

>It used to be much longer, and used to have much deeper
> nesting, and used to contain many little "islands", the nearly
> independent bits the page is from. So, in a such little island I want
> to say that I need here a local variable called x, and I don't want to
> afraid about all the mess this island is in the middle of. But with
> the current rules I have to. It surely depends on what kind of
> templates you have in a project, but maybe for many it will be more a
> burden than a help. Anyway, if we are talking about unintended
> variable hiding, the hiding of data model variables and the hiding of
> .namespace (top-level) variables, which are all allowed, are more a
> risk. So it is inconsistent that we don't allow scoped variables
> hiding each-other, if we allow hiding data model variables and
> top-level variables. It's not what the users expects, I believe.

OTOH, that is the Java approach. YOu can redefine a variable that is
class-level in a method, but then within a lower level of nesting in
that method, you can't redeclare the variable.

Of course, maybe even disallowing the first redeclaration would be
even the most consistent. If the class has a member variable called
"foo", you simply can't have a local variable called "foo" in a method
and that's that. I dunno. More consistent. I don't know if it's
desirable OTOH.

AFAICS, none of it would really create an insuperable problem. I mean,
if you define a variable in a scope called i and then in a more inner
scope, you use i again, and it complains, well, then you use j -- or k
or whatever.

I mean, it could be argued that it is simply better not to allow the
reuse of the variable name like that. Maybe you're just better off in
the long run. If you don't want to be conditioned by any of it, then
just put it all in a new namespace completely. We'd still end up with
the inconsistency where a local variable potentially hides something
in the enclosing namespace.  I was actually wondering about the
desirability of giving people the option of declaring, say, in the ftl
header, all the top-level variables available in a given template
namespace. Then, statiically, at parse-time, you could catch
misspellings. And, of course, using that would be optional, but if you
did use it, you know, something like:

<#ftl vars="x, y, z" ...>

And then if somebody refers to something that's not x, y, or z, as a
top-level variable, then it's a parse-time error. Of course, x.y, and
x.z, if they were errors, could only be caught at render-time...but
you know, at least, optionally, you just state very clearly at the top
of the file what top-level variables are going to be available in this
template, and that allows earlier sanity checking -- at least in use
cases where it makes sense, it's still optional....

I honestly don't know how useful it is. But, in conjunction with the
scoped declarations, you would then basically know at parse-time what
top-level variables are permissible at any point in the template code
-- and maybe that could be useful for tools and so on....

>
> >>
> >> > If there exists a foo variable in the local scope and also in the
> >> > namespace scope, then you would need to write:
> >> >
> >> > <#set foo = "bar" in .namespace>
> >>
> >> Which is consistent as you had to apply similar trick anyway if you
> >> want to read the "foo" variable.
> >
> > Generally, if there is a foo variable in a macro, that is what you
> > want to read and write when you refer to foo in there. That there is
> > occasionally an outer foo defined in the namespace and you need a
> > disposition to get at it, this is necessary for language completeness,
> > but it should not often be used, I think.
> >
> >>
> >> BTW, this .namespace sound me like a misnomer. The .global and even
> >> the local scope are namespaces as well. Shouldn't it be .template or
> >> something
> >
> > Not really, since it could be a library namespace.
>
> FreeMarker has only one kind of file-like unit, that we call
> templates. It doesn't have the concept of libraries, it only have
> templates. Even if in practice some templates are used as a collection
> of macros, without any useful "main" code.

The .main is simply the entry template, yes. And there is, perhaps,
nothing particularly special about that theoretically. Still, I
suspect it's somehow useful (sometimes) to be able to get at that
"main" template namespace from wherever you are. These are things that
very few people use or need to know about even, but are there for
overall language completeness/roundness or whatever.

The thing is that these things have had these names now for nearly 4
years, and to start some big renaming maybe has little real value.

>
> > There is also a
> > .main which is the "main" template namespace, something one might
> > occasionally need to get at.
>
> That's just the .namespace of the initially called template, if I
> remember well.

Yes, the namespace of the initially called template in the overall
processing job. That's .main, I think.

>
> > I think I thought about this and we may
> > have discussed it and, you know, if the alternative is
> > .current_namespace, that's just too verbose, you see, so finally it
> > was .namespace.
>
> Well I have no idea how it went through... such a misnomer.

The more descriptive alternatives seem long,  like I said, like
.current_namespace.

>
> > I've got .scope as well for the innermost scope, but
> > that maybe should be .local_scope or something, but it gets maybe too
> > long to write these things.
>
> "scope" is a pretty bad name as well, but "local" is already used.

Probably .local_scope is the most accurate/descriptive, but  it's
long.... The .scope thing is new so we could change it to a better
name with no BWC implications. Other things we're talking about have
been that way for years now.

>
> OK, so, what names should we use... I think .main, .template (means
> the template we are in) and... what do we need .scope for?

well, at the very least, it just sort of consistently rounds
everything out, that all these things are, in the general sense,
scopes and you can get at them, the current template namespace, the
local variables in your current macro context, and so on.

>
> >>
> >> > If we encourage people to use <#set...> we avoid all that. And,
> >> > anyway, I anticipate at some point having a conversion utility that
> >> > simply converts templates to the new preferred set/scoped syntax.
> >>
> >> And maybe upgrade US Cavalier... and rename it (out of curiosity, why
> >> is that called like that?).
> >
> > It's U.S. Cavalry, and the origin is a little joke. (Killing apaches...)
>
> Ahhh... stupid me. Wasn't Spain also heavily involved in these things?

In killing indigenous people, yes, but not the apaches, I don't think
-- Mayas, Incas, Zapotecs, Yaquis, Mapuches, and so on.... killed most
of them and enslaved the rest most likely.

OF course, if Hungary had had an overseas empire of that size in that
time, you think they would have behaved better? OTOH, it's hard to
have an overseas empire when you don't even have a coastline, isn't
it?

> Can't be a coincidence... :)

THere are no coincidences, only different conspiracy theories.... :-)

>
> > The joke is now old, of course, so if you have a better name (maybe
> > with a newer little joke...)
>
> vm2ftl, Velocity Converter, whatever... something understandable.

That's all okay, but where's the joke? I don't see what's funny.... <shrug>

>
> >> Well if , and I hope that, you will again
> >> feel like hacking stuff. That can be quite fun... better than ******,
> >> as I used to encourage some people. :) Bad to find myself burnt out in
> >> this field sometimes... /-: oh well.
> >
> > I think we're going to see some pretty significant forward movement
> > now again. I really do. There's another idea I am going to float
> > fairly soon that I think could be quite interesting.
> >
> > I actually think maybe this next release cycle should be 3.0.
>
> Aham... what changes do you plan? Something brutal and revolutionary
> maybe?

See the other note about the .ftlx format idea.

JR

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: [FreeMarker-user] parent-child communication, a.k.a. upvalues

Daniel Dekany
Tuesday, May 1, 2007, 1:14:21 AM, Jonathan Revusky wrote:

[snip]
> Of course, maybe even disallowing the first redeclaration would be
> even the most consistent. If the class has a member variable called
> "foo", you simply can't have a local variable called "foo" in a method
> and that's that. I dunno. More consistent. I don't know if it's
> desirable OTOH.

If it is desirable with scoped variables (that I dispute), then it is
desirable for the .namespace variables as well. But it would still
left the problem of hiding data-model variables which are the more
serious "accidental hiding" issue. So... well, you see.

> AFAICS, none of it would really create an insuperable problem. I mean,
> if you define a variable in a scope called i and then in a more inner
> scope, you use i again, and it complains, well, then you use j -- or k
> or whatever.
>
> I mean, it could be argued that it is simply better not to allow the
> reuse of the variable name like that. Maybe you're just better off in
> the long run. If you don't want to be conditioned by any of it, then
> just put it all in a new namespace completely. We'd still end up with
> the inconsistency where a local variable potentially hides something
> in the enclosing namespace.  I was actually wondering about the
> desirability of giving people the option of declaring, say, in the ftl
> header, all the top-level variables available in a given template
> namespace. Then, statiically, at parse-time, you could catch
> misspellings. And, of course, using that would be optional, but if you
> did use it, you know, something like:
>
> <#ftl vars="x, y, z" ...>
>
> And then if somebody refers to something that's not x, y, or z, as a
> top-level variable, then it's a parse-time error.

The thing that spoils this for template languages is the data-model.
You see, if you have ${q} somewhere, and you know that there is no
variable called "q" is declared in the template, then you assume that
it is from the data model, that you don't know when you parse the
template, so, end of story. Unless, you say that non-data-model
variables must be started with some kind of special symbol like @.

> Of course, x.y, and
> x.z, if they were errors, could only be caught at render-time...but
> you know, at least, optionally, you just state very clearly at the top
> of the file what top-level variables are going to be available in this
> template, and that allows earlier sanity checking -- at least in use
> cases where it makes sense, it's still optional....
>
> I honestly don't know how useful it is. But, in conjunction with the
> scoped declarations, you would then basically know at parse-time what
> top-level variables are permissible at any point in the template code
> -- and maybe that could be useful for tools and so on....

I don't know how much perceive it, but the whole overly-dynamic
do-everything-on-runtime apporach of FreeMarker is very bad for tools.
Especially since you use Eclipse I'm certain you know what do I mean.
Now to make variables checkable while editing, you unfortunately must
know the data model... but if the language is a bit more "static"
regarding the variables than FreeMarker is, then at least you can do
the checking if a dummy data-model is provided. There is no that big
obstacle in the case of checking of macro calls, but FreeMarker has
missed that opportunity as well.

>> >> > If there exists a foo variable in the local scope and also in the
>> >> > namespace scope, then you would need to write:
>> >> >
>> >> > <#set foo = "bar" in .namespace>
>> >>
>> >> Which is consistent as you had to apply similar trick anyway if you
>> >> want to read the "foo" variable.
>> >
>> > Generally, if there is a foo variable in a macro, that is what you
>> > want to read and write when you refer to foo in there. That there is
>> > occasionally an outer foo defined in the namespace and you need a
>> > disposition to get at it, this is necessary for language completeness,
>> > but it should not often be used, I think.
>> >
>> >>
>> >> BTW, this .namespace sound me like a misnomer. The .global and even
>> >> the local scope are namespaces as well. Shouldn't it be .template or
>> >> something
>> >
>> > Not really, since it could be a library namespace.
>>
>> FreeMarker has only one kind of file-like unit, that we call
>> templates. It doesn't have the concept of libraries, it only have
>> templates. Even if in practice some templates are used as a collection
>> of macros, without any useful "main" code.
>
> The .main is simply the entry template, yes. And there is, perhaps,
> nothing particularly special about that theoretically. Still, I
> suspect it's somehow useful (sometimes) to be able to get at that
> "main" template namespace from wherever you are.

I don't debate that. I wasn't against .main, that thing is OK, as the
entry template has special role. I was against the name of the
.namespace special variable.

> These are things that
> very few people use or need to know about even, but are there for
> overall language completeness/roundness or whatever.
>
> The thing is that these things have had these names now for nearly 4
> years, and to start some big renaming maybe has little real value.
>
>>
>> > There is also a
>> > .main which is the "main" template namespace, something one might
>> > occasionally need to get at.
>>
>> That's just the .namespace of the initially called template, if I
>> remember well.
>
> Yes, the namespace of the initially called template in the overall
> processing job. That's .main, I think.
>
>>
>> > I think I thought about this and we may
>> > have discussed it and, you know, if the alternative is
>> > .current_namespace, that's just too verbose, you see, so finally it
>> > was .namespace.
>>
>> Well I have no idea how it went through... such a misnomer.
>
> The more descriptive alternatives seem long,  like I said, like
> .current_namespace.

Current? That could be, like, the current "scope"... There are
multiple current namespaces here.

>>
>> > I've got .scope as well for the innermost scope, but
>> > that maybe should be .local_scope or something, but it gets maybe too
>> > long to write these things.
>>
>> "scope" is a pretty bad name as well, but "local" is already used.
>
> Probably .local_scope is the most accurate/descriptive, but  it's
> long.... The .scope thing is new so we could change it to a better
> name with no BWC implications. Other things we're talking about have
> been that way for years now.

Now I sad we didn't called these nested content things blocks. Then it
could be #block.

>> OK, so, what names should we use... I think .main, .template (means
>> the template we are in) and... what do we need .scope for?
>
> well, at the very least, it just sort of consistently rounds
> everything out, that all these things are, in the general sense,
> scopes and you can get at them, the current template namespace, the
> local variables in your current macro context, and so on.

OK. Argh, stupid names... I hate names! So hard to find a good one. No
idea. Except that .namespace being replaced with .template.

>> >>
>> >> > If we encourage people to use <#set...> we avoid all that. And,
>> >> > anyway, I anticipate at some point having a conversion utility that
>> >> > simply converts templates to the new preferred set/scoped syntax.
>> >>
>> >> And maybe upgrade US Cavalier... and rename it (out of curiosity, why
>> >> is that called like that?).
>> >
>> > It's U.S. Cavalry, and the origin is a little joke. (Killing apaches...)
>>
>> Ahhh... stupid me. Wasn't Spain also heavily involved in these things?
>
> In killing indigenous people, yes, but not the apaches, I don't think
> -- Mayas,

Yyouuu bastard! :) The relatives of Magyars ("Hungarians" in Hungarian
language)! (According to some wild circles anyway... eh, don't take
them seriously, I don't.)

> Incas, Zapotecs, Yaquis, Mapuches, and so on.... killed most
> of them and enslaved the rest most likely.
>
> OF course, if Hungary had had an overseas empire of that size in that
> time, you think they would have behaved better?

Well... define Hungarian. You see, you know nothing about this nation,
nor we do much, for that mater, thanks to the continual history
erasing mania of our various rules. And according my best knowledge,
very long ago (900 years ago and so), when they were not called
Hungarians, they had this Manicheist religion, that quite much banned
such things, even if it didn't banned taking over land. If how quickly
did this philosophy decayed (with Christians, etc), if it has existed
at all, and where average Hungarians where morally at later points of
time, who knows. But it doesn't mater now. It doesn't make today
Spains be better or worst guys, nor Hungarian guys. BTW, interesting
your defensive or rather even a little bit attacking reaction is, as I
didn't even said "Yyouuu bastard!" :) in the previous mail. Do other
nations mock you much with these things? I find these things quite
silly. There is little base to blame or praise people for what their
leaders did. Especially when someone points to the past. Like, that
Germans should feel ashamed because of Hitler. What an absurd,
bastard, outrageous idea! Now then, blaming somebody for killing
Indians, well... is at least as stupid, if not double as stupid.

> OTOH, it's hard to have an overseas empire when you don't even have
> a coastline, isn't it?

Well, there was a time when we had a coast line... :)

>> Can't be a coincidence... :)
>
> THere are no coincidences, only different conspiracy theories.... :-)

No need to say that to Mel Gibson...

>>
>> > The joke is now old, of course, so if you have a better name (maybe
>> > with a newer little joke...)
>>
>> vm2ftl, Velocity Converter, whatever... something understandable.
>
> That's all okay, but where's the joke? I don't see what's funny.... <shrug>

There wasn't any joke.

>> >> Well if , and I hope that, you will again
>> >> feel like hacking stuff. That can be quite fun... better than ******,
>> >> as I used to encourage some people. :) Bad to find myself burnt out in
>> >> this field sometimes... /-: oh well.
>> >
>> > I think we're going to see some pretty significant forward movement
>> > now again. I really do. There's another idea I am going to float
>> > fairly soon that I think could be quite interesting.
>> >
>> > I actually think maybe this next release cycle should be 3.0.
>>
>> Aham... what changes do you plan? Something brutal and revolutionary
>> maybe?
>
> See the other note about the .ftlx format idea.

OK, see the answer.

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel