I'm making a library that was built with ENVIRONMENT=web, and now am trying
ENVIRONMENT=node.
For the browser, I'd named the library's functions things like
`mylibEntryPoint()` before. But the pattern in Node is that people say:
var mylib = require('mylib')
So `mylib.mylibEntryPoint()` seems redundant. Better would be
`mylib.EntryPoint()`, or `mylib.entryPoint()`.
But when mylib is actually a `Module = {...}` coming from emscripten, the
resulting object comes with quite a number of fields, which one can see
with:
console.dir(mylib)
There's a fair bit in there, including basic lowercase words (quit, buffer,
arguments) and uppercase ones (HEAP8, ENV, FS), along with plausibly
generic mixed case things (createContext, addFunction, readBinary).
So that seems to run the risk of a conflict. Even if something is not
taken today, it might be in the future.
A safe(r) thing to do might be to have this go in two steps:
var mylib_node = require('mylib-node')
var mylib = mylib_node.ActualLibrary
But even then, one would have to choose the names (and whether getting from
one to the other should be a function or a member--I'm not
javascripty-enough that the "right" thing to do in such situations ever
seems obvious. :-/)
Is there prior art or thinking on this topic?
Best,
--Brian
http://hostilefork.com
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
