Re: Optimising Variable to reduce instantiation overhead

| I don't think it's the same at all.  Synchronization is a safety measure with
| a small performance penalty.  If you can't show that your code is always
| thread-safe, you should synchronize.

Well, we've managed to reduce this down to what it is: opinions!

I _totally_ don't agree with this: (library) code should _never_ be thread 
safe, as a rule of thumb!!

It is generally the _use_ of (library) code that should ensure thread 
safety, if it is necessary in the situation at hand.

I find the Hashtable and Vector and StringBuffer approach of doing things 
"threadsafe" from the start totally utterly backwards, and happily "java" 
is going directly away from this approach (HashMap, ArrayList and 
StringBuilder).

A library should as a rule of thumb be developed in a way that makes 
synchronization unnecessary and indeed _obvious_, and not include "smart" 
stuff within it that requires synchronization (typical example: internal 
smart-ass caches that are there to reduce the impact of badly written 
code). On this aspect, WebMacro has gotten it totally wrong: WebMacro have 
_way_ to much bloat in it, due to the fact that it wasn't really decided 
until "recently" that it shouldn't be a "web framework", but rather "a 
macro-merging utility". However, this hasn't been brougth to the end: 
there are still way to much magic, hidden smarties and bloat within 
webmacro.

The very bad examples are the following:
  *) The concept of "the configurable broker", with way too much 
responsibility.
  *) Reloading of templates, thus forking threads!!
  *) Luckily the _downright idiotic_ "time thread" is already gone, so I 
can sleep better at night.

Those things shouldn't have anything to do with the tight little 
macro-merging utility/library that WebMacro ought to be.

I can't see one reason for why WebMacro couldn't be developed in a way 
that would do _all_ synchronization unnecessary (the lazy init of that 
dear name _might_ constitute an exception, but even there, since this is 
utterly exceptional, this could be done "every time" instead).
  Templates should be immutable and not contain state at all, so that they 
could be shared amongst threads (as they obviously are), but the actual 
sharing of instances should be done in an application-specific way: if you 
didn't handle the caching (and thus synchronization) yourself (by some 
plugin, or whatever), you wouldn't get any, and the whole thing was 
totally linear and un-synchronized (make Template, make Context (or just a 
Map?), merge()).


Note that this isn't just a point about the syncronization per se, but as 
an architectural idea: if things are straightforward, linear, and without 
hidden magic, they _tend to not need_ synchronization, and tend to be much 
easier to understand and not least debug when things doesn't go your way. 
Not to mention the "safe feeling" one gets when a library is truly 
understood and the call-paths are obvious and linear.

Kind regards,
Endre.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642