On Wed, Nov 25, 2015, at 11:08 AM, David Flanagan wrote:
> Why can't we use the standard C preprocessor (with #if, #ifdef,
> #define, and even #include) for this instead of adopting a new
> technology?
The standard C preprocessor results in illegal syntax in JS files and
other files. This is a nightmare for automated tooling that wants to
parse things like eslint and various analysis tools. The jsoverson one
seems to go to some effort to embed things in/understand comments, which
avoids the worst of it, although obviously it is going to defeat any
type of analysis that depends on being aware of what the preprocessor
would do (unless the tooling gets the post-processing output fed to it.)
NB: I think we should avoid using preprocessing at all costs; it seems
like most needs can be addressed through use of a module-system and
conditional selection/replacement of modules at build time. An
optimization pass that performs constant propagation and dead-code
elimination that builds on that also seems preferable. But I'm also
very much of the mind that the people developing and maintaining
code should be making that call. If it's a problem, they'll get
burnt or suffer complaints and can revise their approach as
appropriate.
> P.S. When we do adopt a preprocessor solution, I'm interested to
> explore whether I can use it to include unit tests in the same
> file as the code being tested.
While doctest (https://docs.python.org/2/library/doctest.html) style
minimal tests embedded in comments might make sense, including non-
trivial tests in the code file would suggest your editor isn't meeting
your needs and/or there's a code organization problem.
If it is an editor issue and/or the paths are just unwieldy, something
like https://atom.io/packages/ruby-test-switcher for atom that lets you
switch between your source file and a corresponding test file(s) with
just a hot-key might be a good way to address things.
Andrew
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
