Re: Repeated Hash Concatenation

Thursday, September 2, 2010, 11:08:40 AM, Attila Szegedi wrote:

> Someone could borrow Clojure's persistent collections
> implementation and plug it into FreeMarker.

However that could only be used when the initial hash was made in FTL,
or partially when one of the two joined hashes was made by FTL. Or...
sometimes it worths just converting a hash to the Clojure-ish internal
representation, but it's tricky to decide it with a program when,
there is the problem that then you lose the expected aliasing effect
regarding the original hash (and despite DefaultWrapper breaks that
expectation too, we don't like that, do we...). Anyway, the true
solution would be just add the map type (TemplateMapModel) to FTL
(which would differ from hash because it would support non-string
keys), and then also add a WritableTemplateMapModel interface for
supporting mutable Map-s (and WriteableSequenceModel too). Yeah, I get
why immutable is good, but FTL is not a functional programming
language, nor it has to deal with concurrent programming tasks on the
FTL-level, so... (Sometimes I wondered how feasible a fully
"functional" tamplate language would be (because it makes the
"fragments" a.k.a "blocks" feature a lot more powerful), but I had no
much luck with it unless it's for rocket-scientists. Maybe when
Clojure and Haskell will be commonplace... :) )

> Attila.
>
> On 2010.09.02., at 11:02, Daniel Dekany wrote:
>
>> Thursday, September 2, 2010, 5:13:16 AM, Erin Drummond wrote:
>> 
>>> Hello,
>>> 
>>> The FreeMarker manual states (in:
>>> http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_hashop_cat):
>>> "Note that hash concatenation is not to be used for many repeated
>>> concatenations, like for adding items to a hash inside a loop". I have
>>> a need to do this however. What is the best way to go about it?
>> 
>> a) http://fmpp.sourceforge.net/pphash.html#sect43, "Writable hashes and
>> sequences" is one possible solution (see or even copy-paste the source
>> code).
>> 
>> b) Wrap certain Java Map object in a way so that its methods will be
>> exposed, and then just use the Java API from FTL... This is tricky
>> though. You had to extend BeansWrapper by overriding getModelFactory
>> in a way so that for the Map-s that you want to access with Java API
>> (as oppose to with FTL hash operators like m[k], m?keys, etc) it
>> returns StringModel.FACTORY (or MapModel.FACTORY, but I personally
>> think that's a mess as it mixes the method names with the actual Map
>> keys). StringModel.FACTORY is what BeansWrapper uses for wrapping
>> objects that are just generic POJO-s for him, so don't be confused on
>> the name. getModelFactory could recognize those maps from a marker
>> interface for example. Then you had to use this new ObjectWrapper in
>> the whole application, i.e., do fmConfig.setObjectWrapper(new
>> YourSpecialBeansWrapper() where you *initialize* your set up
>> FreeMarker (that you usually do during application initialization).
>> 
>>> It does actually work in the way that the manual forbids, however I
>>> assume that it is particularly messy or slow otherwise it wouldn't
>>> be forbidden.
>> 
>> When you do H1 + H2 in FTL (where H1 and H2 are hashes), since it
>> treats hashes as immutable(!) data-structures, it will create a new
>> H12 object which just references H1 and H2, and whenever you search a
>> key in H12, it first passes the task to H2, and if that didn't have
>> the key then to H1. This means that after, say, 1000 concatenations of
>> a single-item hashes, whenever you look up a key, you basically do a
>> linear searching in a list of 1000 keys. Ouch! Not exactly the
>> performance what you would expect from a hash. (Yes, there are
>> algorithms for efficiently concatenate immutable dictionaries in way
>> that the resulting dictionary will remain fast... but other than you
>> need to be kind of a Knuth to implement them, you will be out of luck
>> if all that you know about a dictionary is what the
>> TemplateHashModel[Ex] interface exposes... and that's often the case
>> in FreeMarker.)
>> 
>> -- 
>> Best regards,
>> Daniel Dekany
>

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd