Sounds interesting. I’m not sure I understand how this would work. I am willing to explore this with a bit of direction.
I don’t see a debug flag listed here: https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler <https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler> > On Jul 11, 2017, at 11:56 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > I've mentioned the notion of debug-mode beads on the mailing list a couple > of times. It would be great to see this idea explored more. > > By definition, now that you've debugged your code, any type-checking code > path becomes unused in production, which is what we don't want. But > adding code paths that go away in production, or swapping in different > beads during development that have more code paths that check for common > mistakes is certainly within the charter. We want to maximize developer > productivity. > > I think Google Closure Compiler supports a debug flag you can use in > COMPILE::JS blocks that gets dropped in production. If we need to mimic a > similar flag for SWF so code can compile outside of COMPILE::JS blocks > that might be ok. > > -Alex > > On 7/11/17, 1:07 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I just wasted over an hour because I was initializing a BinaryData with a >> string instead of an ArrayBuffer. >> >> I would like to add a typecheck to the bytes argument in the BinaryData >> constructor to throw an error if something other than an ArrayBuffer is >> provided. We cannot use strict typing to catch this in the compiler, >> because the argument is different for SWF and JS. Is this a violation of >> PAYG? It’s sort-of just in case code, but not really because it’s >> protecting against errors. >> >> Thoughts? Other solutions? >> Harbs >
