I was wondering if for how long should we add major features to the
backward compatibility bound 2.3+ line (2.3.x, and 2.4.x). With
FreeMarker 3 I mean shamelessly dropping BC (while remaining
recognizable), move the existing code base to a different package
(like org.apache.freemarker3 or org.freemarker.v3) so that it can be
used in parallel with FreeMarker 2, and cleaning it up from all the
historical mistakes (this includes syntactical adjustments,
introducing FTL3). I'm thinking in refactoring/cleanup in smaller
steps, and rewriting as few parts as possible (like the parser).
Doing this is possibly a turndown for 2.x user, but after 11 years
since 2.3.0, and nearly 0 contribution from the companies relying on
FM, doing this is perhaps not that outrageous. And it's not like 2.3
won't get fixes or even smaller backported features. Anyway, why do I
think it should be done:
* Development costs:
It's possible to play a round with the incompatibleImprovements
setting in 2.x almost indefinitely, but the more fundamental legacy
issues you address, the more expensive it is in terms of developer
time to make that fix optional (i.e., something you can turn on via
incompatibleImprovements), and developer time is scarce. I'm afraid
that without cutting these expenses, most of the deeper fixes will
just never happen or happen too late, also new/innovative features
will delay too much.
* Complexity pushed on the user:
The sometimes confusing legacy public API and the growing amount of
legacy/redundant features, which are confusing for the user, you
can't fix with incompatibleImprovements. So while users who are
dependant on 2.x are possibly better of with messing with this
additional complexity (on the short term at least), all the new
users are negatively affected.
* Attractiveness for new developers:
Dragging all the legacy with us means substantial additional code
complexity and code ugliness. Thus contributions are harder to make,
and most importantly, long term developers are hard to catch.
(Some may ask, what about 2.4? I have kept putting things into 2.3
that were meant for 2.4... like Java 5. I just don't know when and if
anyone will find the energy to release 2.4, for the few remaining
things must remain 2.4-exclusive.)
You may ask what I want to change:
- Dropping all the not-recommended-anymore and deprecated features,
obviously. There's a lot, trust me...
- Rename things that has confusing name, or are in the wrong package
- Unify the concept of macros and (user-defined-)directives. Same with
functions and methods. These are separate concepts yet similar in
the current code base.
- Parser/syntax:
- FTL3:
- Null-aware, has a behavior that's more like Groovy's
- Hash "map" type instead of "hash" (i.e., no string-keys-only BS
anymore)
- Better whitespace handling
- Has simpler, more regular syntax.
- Designed to make user-defined dialects possible
- Some minor changes in expression syntax... doesn't mater for now.
- Separately pluggable expression language and "outer" language
- Made with IDE and template-introspection support in mind
- Template loading/caching:
- A better version of the TemplateLoader mechanism. The current one
has problems with being effective with DB for example.
- In general, template loading/caching need to be more pluggable.
Right now it's often hard to reuse your framework's existing
caching facility for example.
So that's a FM 3.0, plus whatever I have forgotten about. That's a lot
of work you see there, but it's rewarding.
--
Thanks,
Daniel Dekany
