freemarker-devel

[Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Hi again,

I just figured I'd pluck some low-hanging fruit. I hope nobody gets
annoyed at me since I've already implemented these features with no
consultation. It was easier just to do it than to talk about it.

The thing is, I'm on such a roll, it's hard to stop. It's like Jim
Carrey in the Mask whose refrain is: "Sooomebody, stop me!"

You can now use numerical ranges to get the substring of a string.

<assign myString = "foobar">

  ${myString[0..2]}

would output "foo".

You can get the capitalize, lower case, and upper case via the special
keys: "_capitalize", "_lower_case", and "_upper_case".

So:

${myString[3..5]._capitalize}

would output "Bar"


Also, there is _number which converts a string to a number in an
analogous way to how _string converts a number to a string. You can 
also get the length of a string via _length in an analogous way
to how you get the size of a list via _size.

I think this stuff is just plain useful.

Flame away. :-)

Jonathan

P.S. I'm just waiting for someone to tell me that the ability capitalize
a word belongs on the business logic layer... ;-)

Re: [Freemarker-devel] low-hanging fruit

[Attila S. <sze...@fr...>]

----- Original Message -----
=46rom: "Jonathan Revusky" <jre...@te...>
To: <fre...@li...>
Sent: 2002. m=E1rcius 27. 12:38
Subject: [Freemarker-devel] low-hanging fruit


> Hi again,
>
> I just figured I'd pluck some low-hanging fruit. I hope nobody gets
> annoyed at me since I've already implemented these features with no
> consultation. It was easier just to do it than to talk about it.
>
> The thing is, I'm on such a roll, it's hard to stop. It's like Jim
> Carrey in the Mask whose refrain is: "Sooomebody, stop me!"
>
> You can now use numerical ranges to get the substring of a string.
>
> <assign myString =3D "foobar">
>
>   ${myString[0..2]}
>
> would output "foo".
>

This is nice, and indeed useful.


> You can get the capitalize, lower case, and upper case via the spec=
ial
> keys: "_capitalize", "_lower_case", and "_upper_case".
>
> So:
>
> ${myString[3..5]._capitalize}
>
> would output "Bar"
>

See below...

>
> Also, there is _number which converts a string to a number in an
> analogous way to how _string converts a number to a string. You can
> also get the length of a string via _length in an analogous way
> to how you get the size of a list via _size.

Why not stick with _size for strings as well? They now act as ranges =
anyway,
so having consistently named _size operator would be good, IMHO.

>
> I think this stuff is just plain useful.
>
> Flame away. :-)
>
> Jonathan
>
> P.S. I'm just waiting for someone to tell me that the ability capit=
alize
> a word belongs on the business logic layer... ;-)


Okay, here you are: "the ability to capitalize a word belongs on the
business logic layer". Seriously, people can write their own little
TemplateHashModels or TemplateMethodModels for capitalizing, turning =
a
string into number and whatnot and plug that into the model root . Yo=
u can't
possibly cover *all* the transformations people would like to do, and=
 adding
randomly selected ones (eventually justifying the choice by claiming =
these
are "frequently used" or "of general usefulness") is inevitably leadi=
ng to
the bloat of the engine core (which I'd prefer to keep small and
task-focused).

Attila.

>
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>
>
>

Re: [Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Attila Szegedi wrote:
> 
> ----- Original Message -----
> From: "Jonathan Revusky" <jre...@te...>
> To: <fre...@li...>
> Sent: 2002. március 27. 12:38
> Subject: [Freemarker-devel] low-hanging fruit
> 
> > Hi again,
> >
> > I just figured I'd pluck some low-hanging fruit. I hope nobody gets
> > annoyed at me since I've already implemented these features with no
> > consultation. It was easier just to do it than to talk about it.
> >
> > The thing is, I'm on such a roll, it's hard to stop. It's like Jim
> > Carrey in the Mask whose refrain is: "Sooomebody, stop me!"
> >
> > You can now use numerical ranges to get the substring of a string.
> >
> > <assign myString = "foobar">
> >
> >   ${myString[0..2]}
> >
> > would output "foo".
> >
> 
> This is nice, and indeed useful.
> 
> > You can get the capitalize, lower case, and upper case via the special
> > keys: "_capitalize", "_lower_case", and "_upper_case".
> >
> > So:
> >
> > ${myString[3..5]._capitalize}
> >
> > would output "Bar"
> >
> 
> See below...
> 
> >
> > Also, there is _number which converts a string to a number in an
> > analogous way to how _string converts a number to a string. You can
> > also get the length of a string via _length in an analogous way
> > to how you get the size of a list via _size.
> 
> Why not stick with _size for strings as well? They now act as ranges anyway,
> so having consistently named _size operator would be good, IMHO.

I'm not sure. I thought it was better to have a different name, since
that way, you force people to stay aware of whether they're dealing with
a string or a list.

Oh, though actually, come to think of it, there is another, stronger
reason. An object can implement both TemplateScalarModel and
TemplateSequenceModel, so I think the special keys have to be different
or there's an ambiguity.

Actually, though, that brings up another problem that just occurred to
me. There's now an ambiguity about using the range as a dynamic key too.
In the case where the object is both a scalar and a list. Hmm. Well,
currently if it's a sequence, the sublist feature gets priority over
substring... and that has to be documented somewhere -- besides the
code, that is. :-) (That's a bit tricky, but if people do multimodels,
then things can get tricky...)

> 
> >
> > I think this stuff is just plain useful.
> >
> > Flame away. :-)
> >
> > Jonathan
> >
> > P.S. I'm just waiting for someone to tell me that the ability capitalize
> > a word belongs on the business logic layer... ;-)
> 
> Okay, here you are: "the ability to capitalize a word belongs on the
> business logic layer". Seriously, people can write their own little
> TemplateHashModels or TemplateMethodModels for capitalizing, turning a
> string into number and whatnot and plug that into the model root. 

Weeeellll, I anticipated this and I already had my response prepared. (A
card up my sleeve.) There is an additional reason for putting
capitalization and lower case in the core. We can make sure that we use
context-based locale info. 

Currently, that possibility is not leveraged. But...  doing upper/lower
case correctly depends on the locale you're in.

> You can't
> possibly cover *all* the transformations people would like to do, and adding
> randomly selected ones (eventually justifying the choice by claiming these
> are "frequently used" or "of general usefulness") is inevitably leading to
> the bloat of the engine core (which I'd prefer to keep small and
> task-focused).

Well, if you compare the our LOC count to Freemarker Classic, even with
these extra things, we're way way down. Most of the java code in
f.template.compiler is generated by javacc. I've really been over that
code base and tightened it up like a drum. The actual non-generated java
code that we're maintaining in that package is well under 2000 lines
now.

Of course, that's why it's been so easy to add stuff like crazy. The
code has been tightened up like a drum. Superman himself couldn't have
added this many features this fast to the legacy code base.... ;-)

Cheers,

Jonathan

> 
> Attila.
> 
> >
> > _______________________________________________
> > Freemarker-devel mailing list
> > Fre...@li...
> > https://lists.sourceforge.net/lists/listinfo/freemarker-devel
> >
> >
> >
> 
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel

Re: [Freemarker-devel] low-hanging fruit

[Attila S. <sze...@fr...>]

----- Original Message -----
=46rom: "Jonathan Revusky" <jre...@te...>
To: <fre...@li...>
Sent: 2002. m=E1rcius 27. 14:52
Subject: Re: [Freemarker-devel] low-hanging fruit


>
> Oh, though actually, come to think of it, there is another, stronge=
r
> reason. An object can implement both TemplateScalarModel and
> TemplateSequenceModel, so I think the special keys have to be diffe=
rent
> or there's an ambiguity.
>


Valid point.


> Actually, though, that brings up another problem that just occurred=
 to
> me. There's now an ambiguity about using the range as a dynamic key=
 too.
> In the case where the object is both a scalar and a list. Hmm. Well=
,
> currently if it's a sequence, the sublist feature gets priority ove=
r
> substring... and that has to be documented somewhere -- besides the
> code, that is. :-) (That's a bit tricky, but if people do multimode=
ls,
> then things can get tricky...)

I'm a very typical example of a multimodel implementor...
f.ext.jdom.NodeListModel is the most extreme example, altough most mo=
dels in
f.ext.beans are almost as good...

That said, I'd like it if the sequence models could control their own
subsequence generation. Something like adding the

public TemplateSequenceModel getSubsequence(int fromInclusive, int
toExclusive);

method, or probably a subinterface with that method (so it's not mand=
atory
for all). Y'know, maybe it wants to reflect changes in the originator
sequence (like java.util.List.sublist() does), or it just has a more
efficient implementation than being copied into an ArrayList.

> > >
> > > P.S. I'm just waiting for someone to tell me that the ability
capitalize
> > > a word belongs on the business logic layer... ;-)
> >
> > Okay, here you are: "the ability to capitalize a word belongs on =
the
> > business logic layer". Seriously, people can write their own litt=
le
> > TemplateHashModels or TemplateMethodModels for capitalizing, turn=
ing a
> > string into number and whatnot and plug that into the model root.
>
> Weeeellll, I anticipated this and I already had my response prepare=
d. (A
> card up my sleeve.) There is an additional reason for putting

There, now I feel ambushed. ;-)

> capitalization and lower case in the core. We can make sure that we=
 use
> context-based locale info.
>
> Currently, that possibility is not leveraged. But...  doing upper/l=
ower
> case correctly depends on the locale you're in.
>

Sure? AFAIK Unicode characters have their upper/lower counterparts (o=
r lack
of them) unambigously defined, so on Unicode characters this particul=
ar
operation should be locale independent. Again, even if I'm wrong at t=
his
poit the programmer that sticks a Locale object into the model root c=
an as
well stick that same locale object into its implementation of
CapitalizeMethodModel.

> > You can't
> > possibly cover *all* the transformations people would like to do,=
 and
adding
> > randomly selected ones (eventually justifying the choice by claim=
ing
these
> > are "frequently used" or "of general usefulness") is inevitably l=
eading
to
> > the bloat of the engine core (which I'd prefer to keep small and
> > task-focused).
>
> Well, if you compare the our LOC count to Freemarker Classic, even =
with
> these extra things, we're way way down. Most of the java code in
> f.template.compiler is generated by javacc. I've really been over t=
hat
> code base and tightened it up like a drum. The actual non-generated=
 java
> code that we're maintaining in that package is well under 2000 line=
s
> now.
>
> Of course, that's why it's been so easy to add stuff like crazy. Th=
e
> code has been tightened up like a drum. Superman himself couldn't h=
ave
> added this many features this fast to the legacy code base.... ;-)
>

I recognize and deeply respect your effort toward tightening the code=
, but
once tightened we should strive to keep it in that crystalized form. =
I still
don't see how these features add to the overall value of FreeMarker's
primary function - being a great template engine. _capitalize, _lower=
_case
and _upper_case are still a feature bloat to me. From

http://www.c2.com/cgi/wiki?CreepingFeaturitis

"Programmers often miss the distinction between what's needed and wha=
t's
"neat". "

Attila.


> Cheers,
>
> Jonathan
>

Re: [Freemarker-devel] low-hanging fruit

[M. A. S. <m_a...@ya...>]

I have been watching this thread, and it's beginning to worry me. Aside
from the "creeping featuritis" that Attila rightly points out, I am
concerned about name space contamination. I routinely build data models
(specifically, hash models) whose keys are the names of database table
columns. With these sorts of features in place, I am beginning to worry
that many such names might become "outlawed" because the FreeMarker engine
associates semantics with them. For example, if someone had a database
column named "_index" -- not unimaginable by any means -- and I expected
the value of that column in the model, I would instead get the index of a
running variable instead!

Obviously I cannot predict the kinds of names that people will use for
their table columns. This is the reason why I suggested, in an earlier
message, that we should use a unary operator for length determination.

Please reconsider the design before implementing such features.

My $0.02.

Sridhar

--- Jonathan Revusky <jre...@te...> wrote:
> Hi again,
> 
> I just figured I'd pluck some low-hanging fruit. I hope nobody gets
> annoyed at me since I've already implemented these features with no
> consultation. It was easier just to do it than to talk about it.
> 
> The thing is, I'm on such a roll, it's hard to stop. It's like Jim
> Carrey in the Mask whose refrain is: "Sooomebody, stop me!"
> 
> You can now use numerical ranges to get the substring of a string.
> 
> <assign myString = "foobar">
> 
>   ${myString[0..2]}
> 
> would output "foo".
> 
> You can get the capitalize, lower case, and upper case via the special
> keys: "_capitalize", "_lower_case", and "_upper_case".
> 
> So:
> 
> ${myString[3..5]._capitalize}
> 
> would output "Bar"
> 
> 
> Also, there is _number which converts a string to a number in an
> analogous way to how _string converts a number to a string. You can 
> also get the length of a string via _length in an analogous way
> to how you get the size of a list via _size.
> 
> I think this stuff is just plain useful.
> 
> Flame away. :-)
> 
> Jonathan
> 
> P.S. I'm just waiting for someone to tell me that the ability capitalize
> a word belongs on the business logic layer... ;-)
> 
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

Re: [Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Attila Szegedi wrote:
> 
> ----- Original Message -----
> From: "Jonathan Revusky" <jre...@te...>
> To: <fre...@li...>
> Sent: 2002. március 27. 14:52
> Subject: Re: [Freemarker-devel] low-hanging fruit
> 
> >
> > Oh, though actually, come to think of it, there is another, stronger
> > reason. An object can implement both TemplateScalarModel and
> > TemplateSequenceModel, so I think the special keys have to be different
> > or there's an ambiguity.
> >
> 
> Valid point.
> 
> > Actually, though, that brings up another problem that just occurred to
> > me. There's now an ambiguity about using the range as a dynamic key too.
> > In the case where the object is both a scalar and a list. Hmm. Well,
> > currently if it's a sequence, the sublist feature gets priority over
> > substring... and that has to be documented somewhere -- besides the
> > code, that is. :-) (That's a bit tricky, but if people do multimodels,
> > then things can get tricky...)
> 
> I'm a very typical example of a multimodel implementor...
> f.ext.jdom.NodeListModel is the most extreme example, altough most models in
> f.ext.beans are almost as good...
> 
> That said, I'd like it if the sequence models could control their own
> subsequence generation. Something like adding the
> 
> public TemplateSequenceModel getSubsequence(int fromInclusive, int
> toExclusive);

It could be that some people would want that control. OTOH, in most
cases, the subrange thing is kind of obvious what you should do. But
really, I don't see how the above issue can be resolved at the java API
level. 

Basically, at the level of the template language, as currently defined
now (by implementation really) there will always be that ambiguity if we
use the same range syntax when the thing could be interpreted as a
scalar or a list, because if you interpret the multimodel as a string,
then you should give a substring, and if you interpret it in its role as
a list, you should give a sublist.

This is simply a flaw in the template language -- as currently
constructed.

Now, there is a workaround, I have just realized. Suppose you have a
multimodel that implements TemplateScalarModel and also
TemplateSequenceModel, called foo. So, currently, foo[0..2] returns a
sublist with elements zero through 2 of foo, since it's checking first
if the thing is a list and giving you the sublist. But suppose you
actually want the scalar interpretation and you want a substring. That's
getting masked.

You can get it via ("" + foo)[0..2]

You see, the ("" + foo) expression gets turned into a SimpleScalar that
only has one interpretation and then you get the substring instead of
the sublist that you would get via foo[0..2]. 

So, it's not a glaring hole with no workaround... I guess these things
come up when your basic language gets syntactically and semantically
richer... Also, I would think that multimodels are more frequently
list/hash, as opposed to list/scalar.

(The other part is separate and needs a separate response.)

Cheers,

Jonathan

Re: [Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Attila Szegedi wrote:
> 
> > > >
> > > > P.S. I'm just waiting for someone to tell me that the ability
> capitalize
> > > > a word belongs on the business logic layer... ;-)
> > >
> > > Okay, here you are: "the ability to capitalize a word belongs on the
> > > business logic layer". Seriously, people can write their own little
> > > TemplateHashModels or TemplateMethodModels for capitalizing, turning a
> > > string into number and whatnot and plug that into the model root.
> >
> > Weeeellll, I anticipated this and I already had my response prepared. (A
> > card up my sleeve.) There is an additional reason for putting
> 
> There, now I feel ambushed. ;-)

Actually, I'm not sure whether that occurred to me before or afterwards.
However, the lcoale-based stuff is really part of my agenda.

> 
> > capitalization and lower case in the core. We can make sure that we use
> > context-based locale info.
> >
> > Currently, that possibility is not leveraged. But...  doing upper/lower
> > case correctly depends on the locale you're in.
> >
> 
> Sure? AFAIK Unicode characters have their upper/lower counterparts (or lack
> of them) unambigously defined, so on Unicode characters this particular
> operation should be locale independent. 

Check again. My context-sensitive code-completing editor gives me two
options for a method like String.toLowerCase(). One takes no arguments
and the other one takes a Locale. One must therefore conclude that:

someString.toLowerCase(Locale.GERMAN)

and

someString.toLowerCase(Locale.US)

at least *potentially* return different strings. I know for a fact that
in languages whihc use accents, there are different conventions as to
what happens when you capitalize the letter 'é' for example.
Traditionally, in Spanish, capital letters do not have an accent on
them, for example. In French, they typically do. But not always... this
kind of thing could even change between France, Switzerland and Quebec.
The rules are really all there encapsulated in the JDK apparently...  At
least for the major locales.

The hooks are in FM for changing locale on the fly in a template. That's
why TemplateModelRoot now has a getLocale/setLocale and why there is a
new directive called <FMLOCALE ...> defined in FMParser.jj. There is
even a node for it, f.template.compiler.LocaleAssignment. (Go look and
check. I'm not bluffing...)

I am a (formerly fanatical) chessplayer and hence accustomed to looking
several moves ahead. I want all the locale-related stuff to do the right
things even with a locale switching dynamically in the middle of a
document. That's what I was going to set as one of the key design goals
of the Babylon release. 

In fact, I was even preparing to write a long note about this to the
list entitled "The Babylon Manifesto" which is about how we can make
Freemarker into a key piece of internet infrastructure by addressing
these issues really well. We'll leave Vel and WM and all those other
losers in the dust.

I am putting all this energy into FM for a reason. I am not the kind of
guy who thinks small. I'm thinking big. Really, look at it. All the
fancy XML-based transformation stuff is unusable, JSP obviously sucks.
So what is there that really works practically? Template engines, right?
What template engines handle these issues?

Now think about the needs of global e-commerce... (I leave you with that
idea to digest...)

> Again, even if I'm wrong at this
> poit the programmer that sticks a Locale object into the model root can as
> well stick that same locale object into its implementation of
> CapitalizeMethodModel.
> 
> > > You can't
> > > possibly cover *all* the transformations people would like to do, and
> adding
> > > randomly selected ones (eventually justifying the choice by claiming
> these
> > > are "frequently used" or "of general usefulness") is inevitably leading
> to
> > > the bloat of the engine core (which I'd prefer to keep small and
> > > task-focused).
> >
> > Well, if you compare the our LOC count to Freemarker Classic, even with
> > these extra things, we're way way down. Most of the java code in
> > f.template.compiler is generated by javacc. I've really been over that
> > code base and tightened it up like a drum. The actual non-generated java
> > code that we're maintaining in that package is well under 2000 lines
> > now.
> >
> > Of course, that's why it's been so easy to add stuff like crazy. The
> > code has been tightened up like a drum. Superman himself couldn't have
> > added this many features this fast to the legacy code base.... ;-)
> >
> 
> I recognize and deeply respect your effort toward tightening the code, but
> once tightened we should strive to keep it in that crystalized form. I still
> don't see how these features add to the overall value of FreeMarker's
> primary function - being a great template engine. _capitalize, _lower_case
> and _upper_case are still a feature bloat to me. From

Look, I'm going to talk really frankly. 

I think sometimes people object to things and they're not really
objecting to the thing itself, but there's some underlying issue there
that goes beyond what is, you know, ostensibly being objected to. Like,
I think some people are nervous and a bit freaked out about the pace of
change and I'm getting some knee-jerk reactions where people are
objecting to something (anything) but it's almost as if they're just
getting nervous about the pace and depth of change. I mean, recently..
okay, I'll say it... the resistance to even exposing the size of a list,
as if that was something nobody needed... !!??

You see, I guess it does come down to an issue of trust. If you know
some of my other work, like Niggle, for example,  I think you'd be more
reassured about this. I think you'd see that I'm pretty tasteful about
code bloat. I'm the kind of guy who thinks he's made a lot of progress
on a coding day when he has fewer lines of code at the end of the day
than he did at the beginning. I mean that, really. :-)

I have no desire to address stuff on the view layer that is
inappropriate or just add bloat because it can be done. Also, as a
framework writer, I just want FM to be a template engine. I don't want
it to be a framework. I very badly wanted to axe ExtendedList which
contained that shelflife stuff because I felt that was inappropriate. I
have certainly axed more code so far than I've added. Lazarus has far
fewer lines of code than FM Classic.

OTOH, I think that capitalizing a word is a nice convenience at the
display level and it shouldn't be something that you have to go to the
engineers to get implemented. Similarly, for all of it, multiplying the
Euro price by 6.556 to get the price in French francs, you should not
have to talk to the developers for that either.

Look, for a long time, Freemarker did not even have integer arithmetic.
I suppose that when people asked about it, you'd have to say that
integer arithmetic wasn't so important and talk about all of FM's other
virtues -- which it did have. And that's what you have to say, in a
sense... but hey, look, don't actually believe it! :-)

I think the WM/Vel people have been telling their user base that nobody
needs floating point for so long that they actually have conned
themselves and they now really believe it! 

<LOL>

Well, let them keep believing it for all I care... :-)

> 
> http://www.c2.com/cgi/wiki?CreepingFeaturitis

Well, adding features, in and of themselves, is not what constitutes
featuritis. Really, features per se, are basically a good thing. The
"featuritis" problem is that you support all these marginally useful
features, particularly that have been sort of strapped and cobbled on,
and basically, you get bogged down carrying around all that crap and you
can't really move the code base forward any more. You can't refactor and
you're stuck. 

Not only are we not suffering from that problem, but there is basically
no risk that I am taking you there. People who are in the code like
Attila and Nicholas surely know what I did before adding numerical
support or anything else. I tightened up the code like a drum first. I
aggressively refactored, chopping thousands of lines away -- with
absolutely no concern for who was ego-involved with whatever code I was
eliminating. (I think that's the right way.)

One of the telltale signs of the featuritis syndrome is code bloat.
Since FM 2.0 has a far lower line count than FM 1.7.x. I think it's very
hard to seriously maintain that we have a featuritis problem.

> 
> "Programmers often miss the distinction between what's needed and what's
> "neat". "

Look, for crying out loud, being able to do 4-function arithmetic on
numbers or to get the size of a list or to get the upper case of a
string is not just "neat". When I start implementing numerical analysis
algorithms in Freemarker (or well before I get to that point) please do
stop me. But meanwhile, you should really take stock of what you're
saying. I don't think that any objective person would really want to
maintain that these features are not needed. Every single feature that I
am adding, from the arithmetic to getting the size of a list to getting
the capitalization of a word, these are things that have frustrated
end-users ever since day one.

Yes, there have always been workarounds. There was a class called
Increment and a class called Decrement, but really, it's kind of nice to
just write <assign x=x+1, y=y-1>.

Cheers,

Jonathan

P.S. We can discuss the exact syntax and semantics etcetera, fine. But
to me, the whole idea that I'm adding things that qualify as
"featuritis" verges on the absurd. Freud, among others maintained 
(correctly, IMO) that people do not really know why they do things. You
might have to look deep inside yourself and figure out why you're
maintaining that something like getting the upper case of a word or the
size of a list is "featuritis".



> 
> Attila.
> 
> > Cheers,
> >
> > Jonathan
> >
> 
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel

-- 
Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://revusky.com/hacks/

Re: [Freemarker-devel] low-hanging fruit

[Attila S. <sze...@fr...>]

----- Original Message -----
=46rom: "Jonathan Revusky" <jre...@te...>
To: <fre...@li...>
Sent: 2002. m=E1rcius 27. 22:50
Subject: Re: [Freemarker-devel] low-hanging fruit


>
> Look, I'm going to talk really frankly.
>
> I think sometimes people object to things and they're not really
> objecting to the thing itself, but there's some underlying issue th=
ere
> that goes beyond what is, you know, ostensibly being objected to. L=
ike,
> I think some people are nervous and a bit freaked out about the pac=
e of
> change and I'm getting some knee-jerk reactions where people are
> objecting to something (anything) but it's almost as if they're jus=
t
> getting nervous about the pace and depth of change. I mean, recentl=
y..
> okay, I'll say it... the resistance to even exposing the size of a =
list,
> as if that was something nobody needed... !!??
>

I'm going to talk frankly as well. I still say that I deeply apprecia=
te the
energy you put into the FreeMarker, and you certainly pushed it in a =
right
direction on several fronts: adding number support, using a formalize=
d
grammar, cleaning up the exception model. FreeMarker was greatly enri=
chened
by these efforts.

But, now I feel that your momentum is pushing FreeMarker toward somet=
hing
that it shouldn't be.
When arguing, please don't blur things. I certainly never resisted to=
 adding
numerics, or to the cleanup of the exception model. I even acknowledg=
ed the
need for a list size (but only after a user - Sridhar - also raised h=
is
voice expressing he would find it useful). I'm arguing against the ne=
ed for
capitalize, lowercase, uppercase and related stuff. Okay, even if the=
y stay
in there, they are *SECONDARY* to a template engine. Yet, they interf=
ere
with a *PRIMARY* function - access to an element of a hash using the =
Dot. In
another post, you recommend to Sridhar that he uses DynamicKey syntax
instead everywhere. Or to implement a "kludge". Yet, you're advocatin=
g that
users aren't paying attention to details, and that we should hide awa=
y
complexity from them as much as we can. Let's do it then.

Here is the key point:
- some backward incompatibilities are inevitable, like 2+2 =3D 4 inst=
ead of
22.
- some backward incompatibilities are unnecessary, like breaking a ve=
ry
fundamental operator, the Dot so that we can introduce magic keys. I =
again
urge you that you introduce a new syntax for special keys, one that
*doesn't* conflict with Dot. It's easy, will provide *more* backward
compatibility, and will keep users happy. In case you didn't notice, =
we now
have an unhappy user that bases his successful commercial product on
FreeMarker. Instead of recommending him the workarounds, and thus shi=
fting
the work to his side, let's do the work ourselves. Frankly, why does
${list#size} or ${list..size} or even ${#size(list)} looks so much ug=
lier
than ${list._size}? For me, that is the most ugly solution since it b=
reaks
backward compatibility where it need not.


> I have no desire to address stuff on the view layer that is
> inappropriate or just add bloat because it can be done. Also, as a
> framework writer, I just want FM to be a template engine. I don't w=
ant
> it to be a framework. I very badly wanted to axe ExtendedList which
> contained that shelflife stuff because I felt that was inappropriat=
e. I
> have certainly axed more code so far than I've added. Lazarus has f=
ar
> fewer lines of code than FM Classic.

Okay, then here's another alternative: create the freemarker.utility
package, and add a StringUtilities class to it. It could be a hash, w=
ith
keys named "capitalize", "lowerCase", "upperCase", etc. which are the=
mselves
method models. It could be constructed with a Locale to ensure locale
sensitive operation. One could plug it in its model root (much like
transformations are plugged now), and use that. You see, we have plen=
ty of
solutions that don't involve hardwiring all of this functionality int=
o the
engine itself. Or you could write a CapitalizeTransformationModel. Th=
ere are
plenty of possibilities, and they all avoid "addressing stuff on the =
view
layer" in the engine core.

>
> >
> > http://www.c2.com/cgi/wiki?CreepingFeaturitis
>
> Well, adding features, in and of themselves, is not what constitute=
s
> featuritis. Really, features per se, are basically a good thing. Th=
e

Features that break backward compatibility, and that can be implement=
ed
alternatively so that they don't break are NOT a good thing.


> I aggressively refactored, chopping thousands of lines away -- with
> absolutely no concern for who was ego-involved with whatever code I=
 was
> eliminating. (I think that's the right way.)
>

I agree with that there should be no respect for ego.

> One of the telltale signs of the featuritis syndrome is code bloat.
> Since FM 2.0 has a far lower line count than FM 1.7.x. I think it's=
 very
> hard to seriously maintain that we have a featuritis problem.
>


Feature bloat and LOC don't correlate directly. Feature bloat is when=
 a
feature is in a place where it shouldn't be. It can be two lines of c=
ode.


> >
> > "Programmers often miss the distinction between what's needed and=
 what's
> > "neat". "
>
> Look, for crying out loud, being able to do 4-function arithmetic o=
n
> numbers or to get the size of a list or to get the upper case of a
> string is not just "neat". When I start implementing numerical anal=
ysis
> algorithms in Freemarker (or well before I get to that point) pleas=
e do
> stop me. But meanwhile, you should really take stock of what you're
> saying. I don't think that any objective person would really want t=
o
> maintain that these features are not needed. Every single feature t=
hat I
> am adding, from the arithmetic to getting the size of a list to get=
ting
> the capitalization of a word, these are things that have frustrated
> end-users ever since day one.
>
> Yes, there have always been workarounds. There was a class called
> Increment and a class called Decrement, but really, it's kind of ni=
ce to
> just write <assign x=3Dx+1, y=3Dy-1>.

You're blurring things again. I'm not labeling ALL of your work a fea=
ture
bloat. On the contrary, much of it is very clean and very important. =
I'm
even willing to accept a capitalization facility PROVIDED it doesn't =
break
Dot. Having arithmetic is good, and the price of having 2 + 2 !=3D 22=
 is worth
it. Having capitalization is not good, it's just nice, and is not wor=
th
breaking the dot. Other special keys are also nice, not good (all can=
 be
replaced by a proper TemplateMethodModelEx) and are also dwfinitely n=
ot
worth breaking the dot. Yes, you can warn users that certain hash key=
s are
reserved, but will they feel comfortable with a template engine that =
has
reserved hash keys?


>
> Cheers,
>
> Jonathan
>
> P.S. We can discuss the exact syntax and semantics etcetera, fine. =
But
> to me, the whole idea that I'm adding things that qualify as
> "featuritis" verges on the absurd. Freud, among others maintained
> (correctly, IMO) that people do not really know why they do things.=
 You
> might have to look deep inside yourself and figure out why you're
> maintaining that something like getting the upper case of a word or=
 the
> size of a list is "featuritis".
>

Blur again. I never claimed that list size is a featuritis (*provided=
* it
does not break the dot).
As for my motivations, I just feel you're moving too fast and try to =
balance
it. Part of this is that I have up to this day corrected three bugs i=
n your
new features that fortunately didn't come out in production.

Re: [Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Attila Szegedi wrote:
> 

> Okay, then here's another alternative: create the freemarker.utility
> package, and add a StringUtilities class to it. It could be a hash, with
> keys named "capitalize", "lowerCase", "upperCase", etc. which are themselves
> method models. It could be constructed with a Locale to ensure locale
> sensitive operation. One could plug it in its model root (much like
> transformations are plugged now), and use that. 


No, no, no and NO! Let me explain....

The ability to capitalize a word *must* be in the core. Little dipshit
passive-aggressive geek programmers must *not* have the ability to play
power games with the designers (or other non-technical types) over
whether or not they really need the ability to put a string in upper
case.

If somebody working at the page design level wants to put the title in
upper case, the feature is going to be there, period. That's how we
expand our user base. We empower ordinary people to get their jobs done.
We don't empower geeks to screw around with ordinary people. If ordinary
people are empowered by it, demand for the tool will bubble up.

(Yes, we avoid feature bloat, and ridiculous special-interest stuff, but
the ability to change a variable to upper case when designing a page is
not feature bloat.)


> You see, we have plenty of
> solutions that don't involve hardwiring all of this functionality into the
> engine itself. 

No, you're wrong. We don't.

>Or you could write a CapitalizeTransformationModel. 

Nope, doesn't work. We're not giving the dipshits in IT the power to
decide whether the regular people trying to do their jobs can capitalize
a word or not. It's going in the core, where it belongs.

We can discuss syntax a bit. I'm going to think about the # or other
possible syntax. 

But it's going in the core. It's either going into the core of
Freemarker, or it's going into the core of an alternative template
engine that I fork off that is based on Freemarker. Up to you.

But it's going in the core. The only point of negotiation is the syntax.
I am currently thinking about that and may have some various proposals
that people can vote on.

Regards,

Jonathan

P.S. You also seemed to miss the real thrust of my previous message. I
even mentioned Freud in the last bit. If the reason you're objecting to
something is technical, we can deal with it on technical grounds. But I
am now sensing a level of second-guessing everything I propose that is
not really technically-based. It's  as if you're objecting in a
knee-jerk emotional way and coming up with the technical reasons later.
If the problem is not technical (but political, emotional,
psychological) then it cannot be resolved technically. What we have is
about as good a technical solution as we're going to have. Introducing a
new, unfamiliar syntactical element is possible but does not strike me
as necessarily better.

Re: [Freemarker-devel] low-hanging fruit

[Attila S. <sze...@fr...>]

----- Original Message -----
=46rom: "Jonathan Revusky" <jre...@te...>
To: <fre...@li...>
Sent: 2002. m=E1rcius 28. 12:40
Subject: Re: [Freemarker-devel] low-hanging fruit


>
> Nope, doesn't work. We're not giving the dipshits in IT the power t=
o
> decide whether the regular people trying to do their jobs can capit=
alize
> a word or not. It's going in the core, where it belongs.
>

Dipshits? I can only hope that no potential user on the developer sid=
e will
take this name-calling personally. At least my English vocabulary got
enrichened with a new word... Designers get to use a template engine =
only
after it is exposed to them by the developers. If they get insulted, =
they
most certainly won't choose FreeMarker.

>
> But it's going in the core. It's either going into the core of
> Freemarker, or it's going into the core of an alternative template
> engine that I fork off that is based on Freemarker. Up to you.
>

We've now hopefully worked this out to everyone's satisfaction so the=
re no
longer is a dissent, but let me point you to a fact:
whether you'll fork off another project is up only to you, and has no=
thing
to do with me. I don't control your acts. Forking off is usually a si=
gn of
deep dissent and insufficient goodwill or patience to resolve it
cooperatively. But (I repeat myself) I guess we're through that now.

Cheers,
  Attila.

Re: [Freemarker-devel] low-hanging fruit

[Jonathan R. <jre...@te...>]

Attila Szegedi wrote:
> 
> ----- Original Message -----
> From: "Jonathan Revusky" <jre...@te...>
> To: <fre...@li...>
> Sent: 2002. március 28. 12:40
> Subject: Re: [Freemarker-devel] low-hanging fruit
> 
> >
> > Nope, doesn't work. We're not giving the dipshits in IT the power to
> > decide whether the regular people trying to do their jobs can capitalize
> > a word or not. It's going in the core, where it belongs.
> >
> 
> Dipshits? 

Yes, dipshits. It's a technical term that you might not be familiar
with, though I am sure you have dealt with dipshits before, without
knowing the appropriate technical terminology.

The term refers to a certain kind of person. Let me tell you an
illustrative story. About 4 years ago, I had some remote work for a
company in the States. It's a long while ago, but I think this is
roughly what happened. For some reason, I think it was the CVS client I
was using on 'Doze would not let me create directories on the server. It
let me do everything else, but for some reason, I couldn't create a new,
empty directory. (The story sounds weird but it's true. Note that this
was my first ever time using CVS so if there was a simple way to get
around this, I didn't know it.) It was just a bug really in the CVS
client I was using. But every time I needed to create one or more new
directories -- you know, directories are a convenient way to organize
your work -- I had to ask some sysadmin guy to do it for me.

This guy started playing games with me. He started questioning whether I
needed to create so many new directories, like maybe I could put my
stuff in just one or 2 directories instead of 3 or 4. (Like there's a
limited supply...) He started questioning my choice of naming for the
proposed directories.... All of this was only because of a glitch in my
software or their setup which let me do anything I wanted except create
a new directory. 

The technical word for a person like that is a "dipshit". Such people
exist and we have to do our best to deal with them. The stereotype of IT
people being passive-aggressive antisocial people, like all stereotypes,
is not always true by a long shot, but there are enough of them and the
stereotype did not emerge from nothing at all.


> I can only hope that no potential user on the developer side will
> take this name-calling personally. 
> At least my English vocabulary got
> enrichened with a new word... Designers get to use a template engine only
> after it is exposed to them by the developers. If they get insulted, they
> most certainly won't choose FreeMarker.

I've said this before. There are three groups to consider:

(a) Non-programmers hacking the templates.

(b) Run-of-the-mill programmers.

(c) Programmers who really know their stuff and know what they're doing.

As I pointed out earlier, groups a and b outnumber group c by about
100-1. 

If you want to understand the philosophical basis on which I make
decisions, it's simple.

Given a choice between inconveniencing group a and group b, I will
inconvenience group b, because group (a) is really the final user.
They're the people being empowered by the technology. If it comes down
to a choice between inconveniencing group (b) and group (c), I will
inconvenience group (c) because group (c) can be thrown off-balance and
they can handle it. 

I am also aware that group (c) is over-represented on these kinds of
mailing lists so I discount the group (c)  viewpoint a bit on that
basis. For example, you are definitely part of group (c) and I
understand your viewpoint, so I overcompensate in favor of groups (a)
and (b) in my consideration.

I say unashamedly and I use the term again. Dipshits. We are not letting
dipshits from group (b) play power games with group (a) over whether
they really need to be able to capitalize a word. 

In any case, another thing is common sense. If some Math nerd wants to
expose some weird mathematical function on a template function, it is
normal that he has to go talk to some computer geek who will do it for
him. OTOH, if some normal person from group (a) wants a string to be in
upper case when it's used in a title, he should not have to go talk to
the computer geek. This is just a question of common sense.

(NOTA BENE: I can refer to other computer professionals as "geeks" or
"nerds" if I want because I am one myself. This is similar to the way
black people can use the "N" word but white people cannot.)

> 
> >
> > But it's going in the core. It's either going into the core of
> > Freemarker, or it's going into the core of an alternative template
> > engine that I fork off that is based on Freemarker. Up to you.
> >
> 
> We've now hopefully worked this out to everyone's satisfaction so there no
> longer is a dissent, but let me point you to a fact:
> whether you'll fork off another project is up only to you, and has nothing
> to do with me. I don't control your acts. Forking off is usually a sign of
> deep dissent and insufficient goodwill or patience to resolve it
> cooperatively. But (I repeat myself) I guess we're through that now.

No, we're not anywhere near a rupture point yet. I was getting a bit
annoyed and the "threat" is not very real. I, at least, am extremely
aware of the fact that we'd all lose. 

OTOH, if we were to get to that point (which I don't think is very
likely) it would result from a complete communication breakdown and I
think there would then probably be blame to go around.


> 
> Cheers,
>   Attila.
> 
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel

-- 
Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://revusky.com/hacks/