These all sound like good changes, and clarify what is really going on.

  

Removing object wrapping IMO is more important than removing the
*Template*Model* interfaces. These interfaces don't have the same runtime and
GC overhead as object wrapping and they can be nice for type checking to make
sure the operation in the template can actually be done on the object. Still,
with those interfaces it would be nice to use more standard ones where they
exist (Java collection interfaces for example).

  

On the object wrapping topic there might be some useful things to learn from
Groovy, though as FTL doesn't compile to a class not all of the same applies.
The biggest performance overhead in Groovy is all the type conversions that it
does to be a type optional scripting language. I've done a lot of work on
optimizing Groovy code since I made a decision years ago to write a big
framework mostly in Groovy.

  

I don't know that this is directly applicable to the discussion, but here is
an article I wrote last year on some stuff I learned about Groovy
optimization, and it may be that we can avoid some of these issues:

  

https://dzone.com/articles/how-to-make-groovy-as-fast-as-java  

  

Even Groovy has a sort of object wrapper, ie its meta class. It's one thing
that would be great to disable when you're not using the Groovy features that
rely on it... maybe someday I'll even look into this in Groovy itself or open
the discussion in that community (for now I'm up to my neck in work :) ).

  

A good step in the right direction might be to start with the use of standard
Java interfaces. For example when you do a #list it could be required that the
object you are iterating over implements either the List or Iterator
interfaces (perhaps with optimization to detect RandomAccess lists like
ArrayList to avoid creating an Iterator). This doesn't get us all the way down
the road, but is a start.

  

-David

  

![](https://link.nylas.com/open/5xm8m568zhx9qyloglsg31huz/local-
178b2039-1688?r=ZGV2QGZyZWVtYXJrZXIuaW5jdWJhdG9yLmFwYWNoZS5vcmc=)

  
On Feb 24 2017, at 9:18 pm, Daniel Dekany <[email protected]> wrote:  

> In FM3, I propose removing some legacy complexity:

>

> \- Remove BeansWrapper, which is the super class of  
  DefaultObjectWrapper, and add its functionality directly to  
  DeafultObjectWrapper. That we have this class hierarchy has purely  
  historical reasons. (Even if FM2, using pure BeansWrapper is  
  deprecated, and causes lot of pain and confusion because it's still  
  possible.)

>

> \- Remove the following BeansWrapper/DefaultObjectWrapper  
  settings, because they just exist in FM2 so that you can chose  
  between FM 2.3.0 compatibility and a better functionality:

>

>   - BeansWrapper.simpleMapWrapper (DefaultObjectWrapper ignores it)  
  - DefaultObjectWrapper.forceLegacyNonListCollections (will be in  
    effect false)  
  - DefaultObjectWrapper.iterableSupport (will be in effect true)
>

> PS I know that there's an idea of removing  
ObjectWrapper-s/TemplateModel-s altogether, and using a MOP instead,  
but that's a fairly brutal change and who knows if it will be  
affordable. So while I try not to invest much into  
ObjectWrapper-s/TemplateModel-s until we figure that out, I do at  
least want to remove stuff that we won't need for sure. And also, baby  
steps, easy things first... keep FM3 working all the time.

>

> \--  
Thanks,  
 Daniel Dekany

Reply via email to