Me, on the blackboard:
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
...
Allows a lambda to execute a template in the lambda's own context. This enables
'late bound' template inclusion where the lambda can select a template based on
dynamic data in the context at the time it is executed.
Closes#92.
This ensures that if you enter a conditional block while inside a list
block, the list "state" from the outer list will still be visible. For
example (somewhat contrived, but gets the point across):
{{#list}}
{{#name}}{{-index}}. {{.}}{{/name}}
{{^name}}{{-index}}. No name!{{/name}}
{{/list}}
Yields something like:
1. Bob
2. Mary
3. No name!
4. Jim
Fixes#90.
You can't normally reflectively access methods on Map because it has a
special fetcher, but being able to reflectively access 'entrySet' is
super useful when you want to iterate over the keys+values of a map, so
we're going to hack it in there. Ha!
For some reason I sort of blocked from my mind the fact that none of the actual
tests were running in GWT. Really I was just testing that things compiled.
So now the tests actually run in GWT. This means I had to split the tests that
rely on method/field lookup via reflection into a separate file because that
stuff will never work with GWT. I also changed a bunch of the other tests not
to surreptitiously use reflection because they were ostensibly testing
something else, so no point in those tests being GWT-incompatible just for
kicks.
This also means we can't use JUnit 4 annotations (sigh, I wish GWT would step
out of the stone age, but that's a whole other fiasco that I don't even want to
think about). So some of the tests that were using @Test(expected=FooException)
had to be rewritten to manually catch the exception and fail if it was not
thrown.
Anyhow, now most of the tests are in fact running in GWT (when you do "mvn
integration-test") and the test that I expected should fail in GWT is in fact
failing. Yay!
There's unfortunately no sane way to do the same reflection-like array access
in GWT, so we just have to enumerate all of the primitive types.
I could have just left this only in the Java backend, but I would prefer to
avoid differences between behavior on the JVM and behavior in GWT whenever
possible.
Michael Bayne