On Wed, 2017-01-11 at 11:55 +0100, Daniel Dekany wrote: > > (3) Move TemplateModel interfaces and standard implementations from > o.a.f to o.a.f.model > > Template models is a topic that's easy to understand for the users > (mentally and technically separate from the other concerns), so we > could decrease the surface area of the o.f package API with this. > > As of the TemplateModel implementations, let's say for now that we > move them over from o.a.f too. Though there will be some more moving > around in that department, together with BeansWrapper and its friends, > but that's for another day.
This may also be a topic for another day, but IIRC there was some discussion about getting rid of many of these interfaces in FM3. I like the idea of more generally using standard interfaces such as java.util.List and java.util.Map, and even more generally avoiding the object wrapping that FreeMarker currently does. This may complicate some of the internal introspection code and possibly even make certain things slower, but overall avoiding object wrapping helps a lot with memory and garbage collection overhead and makes the template engine more flexible. On the topic of using more standard Java interfaces and API: many built-ins can be eliminated in favor of existing API methods, though perhaps some current FreeMarker users prefer the ?foo syntax of built-ins versus the .foo() syntax of API calls. For any new built-ins, like the date/time ones recently discussed, they could at least be inspired by the more standard Java APIs like the java.time classes as opposed to the Joda Time ones. Joda Time is a great little package, but for stuff I've been doing lately it has been very nice to migrate to the java.time stuff. Not that Joda Time inspired built-ins would actually require Joda Time, but it is great that many open source libraries I use have moved to java.time to eliminate the Joda Time dependency, enough that I've been able to remove that dependency completely (speaking the Moqui Framework project). All of this falls into the category of avoiding redundant code and standards (interfaces and such). IMO when something in the standard Java API is available and adequate it should be preferred over alternatives. This lowers the learning curve and has the potential to make things run faster and more efficiently as well. -David
