Actually, setting properties on the context's global object still works. I
found the difference between a script and a module is in re-declaring the
variables. For example:
Assuming h and w are two properties defined to be "hello" and "world" on
the global object, the following line:
var h;; var w; h + ' ' + w;
=> hello world (when evaluated as a script)
=> undefined undefined (when evaluated as a module)
while the following:
h + ' ' + w;
=> hello world (as a script)
=> hello world (as a module)
It would be nice to allow the embedder to set properties on the module
namespace object, so that each module has its own isolated variable
bindings. Is that possible?
On Wednesday, January 2, 2019 at 9:55:26 PM UTC-8, Jane Chen wrote:
>
> Hi Ben,
>
> I checked out Module API on v8 6.7 and it was working great, except one
> problem: I lost a way to bind external variables to the global object used
> for module evaluation. I have tried setting them on the global object of
> the context, the module namespace object (return value of
> Module::GetModuleNamespace()), and the global object template for context
> creation, but nothing worked. I know that there's syntax for a module to
> import external variables. But for backward compatibility, I'd like to be
> able to set some global variables for module evaluation. Is there anyway
> to do that?
>
> Thanks a lot!
>
> On Saturday, May 12, 2018 at 4:38:15 AM UTC-7, Ben Noordhuis wrote:
>>
>> On Sat, May 12, 2018 at 6:42 AM, Jane Chen <jxch...@gmail.com> wrote:
>> > Thanks Ben.
>> >
>> > I want to re-use my context for performance reasons, but some
>> JavaScript
>> > programs have constant global variables that cannot be re-defined, such
>> as
>> > those declared with let or const. To work around this, I thought I
>> could
>> > just evaluate each program in a closure by artificially enclosing the
>> script
>> > with {}. Do you see any issue with doing it?
>>
>> I don't see anything wrong with that but if you reuse the context, you
>> have to scrub globals introduced with `var`, undo any monkey-patching
>> of builtins, figure out how to cancel pending promises, etc. Using a
>> new context is probably a lot simpler and robuster.
>>
>> > Is there any better way to do so?
>>
>> You could compile your code as an es6 module or with
>> v8::ScriptCompiler::CompileFunctionInContext() but you'd probably have
>> to upgrade first. Modules don't exist in V8 5.3 and
>> CompileFunctionInContext() has a bug where the line and column in
>> stack traces are wrong.
>>
>> Modules and functions have different run-time semantics than a
>> top-level script, of course, so they might not be a good fit if
>> backwards compatibility is a concern.
>>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
