Looking at the this line closely from "Advanced Compilation and
Externs" [1]:
"Closure Compiler compilation never changes string literals in your
code, no matter what compilation level you use...
Whenever possible, use dot-syntax property names rather than quoted
strings. Use quoted string property
> Well, Showdown is not really a namespace right? It's an object in the
> global environment. You should be able to grab it via js/Showdown and do
> all kinds of interopey things to it.
Right, I totally agree. Where the problem occurs though in this
particular scenario is when :optimizations is
Well, Showdown is not really a namespace right? It's an object in the
global environment. You should be able to grab it via js/Showdown and do
all kinds of interopey things to it.
On Aug 5, 2011 4:27 PM, "Alen Ribic" wrote:
> Thanks Fogus for clearing that up.
>
> Would a call to a constructor
Thanks Fogus for clearing that up.
Would a call to a constructor function in a namespace of a third-party
library be an exception for the time being? (I can't seem to see a
clear way you can express that via `js` namespace.)
Example:
> new Showdown.converter().makeHtml(~{b-txt},~{safe})
Showdown
To access global JavaScript interop thingies (a technical term) you
should use the `js` namespace. The use of `js*` should be considered
a bad idea. It's used in core, but only for very low-level
operations. It should be considered undocumented and therefore off-
limits (we're working to elimina
Currently, you can wrap the JS call in js* like so (js*
"MyLib.doSomething(arg1,arg2)").
So this will pass the compile time without resolving the external lib
calls.
It is worth noting that you may come across an interesting problem
that I did in similar scenario to yours.
If you set the optimizat
