Allows for monkey patching (under ES5 systems). This somewhat mirrors
the proposed behavior in https://github.com/square/es6-module-transpiler/issues/37
but applies the behavior via manual code changes rather than compiler
support.
Using prototype has a large performance impact for the common case of a
sparse set of private variable data points. Rather than incurring the
overhead of creating and walking the prototype tree for this, performing
an extend by copy.
Using string.toString() will throw errors in current versions of Safari
(6.0.5 currently) for some values. The error is a particularly cryptic
"Type Error: type error", which no indication as to the value that
caused the error. By using the '' + string form of coercion the error
doesn't seem to occur.
Depending on the browser used there is a sizable performance increase
in using the concatenation form of coercion. In instances where there
is not a performance improvement (i.e. Firefox), the speed difference
is entirely negligable. See: http://jsperf.com/convert-to-string-bj/3
The basic strategy is that there will be a global Handlebars object for
the browser build, and that object will have a `compile` on it which
uses its environment in the compiler.
It will also be possible to glue things together manually by using the
AMD build and passing the environment to `compile` directly. Some of
these details are TBD.
The idea is that the environment wraps up the mutable stuff in
Handlebars (like the helpers) and that you could theoretically create a
new one at any time and pass it in to Handlebars.template.
Every test makes a new environment and uses it in template compilation.