Re: [w3ctag/design-reviews] Realms API ECMAScript Proposal (#542)

Hi @LeaVerou!

> How does one import named (or default!) exports with different names than the ones they were exported with?

As pointed out in the last example in [this comment](https://github.com/w3ctag/design-reviews/issues/542#issuecomment-840861621), user land code would need to serialize multiple names.

> Also, how can someone do the equivalent of import * as foo from ... with this?
Needing to repeat the import URL/specifier for the extremely common case of importing more than 1 export is ...not ideal.
I think the importValue() API needs some work…

I fully understand the concern and that's something we considered. Although, there are some differences for operations between realms.

First, for `import * as foo from 'module'`, this would need to import a module namespace. In this current callable boundary API, we can't have access to objects cross realms. So we would need to set internal code to clone an object structure for this module namespace, and this would need to go through some overkill internal checkups. 

- this clone would need to lose the binding mapping. Module Namespace have a dynamic mapping of the values, a cloned object structure would need to block that and have only property keys with their direct values.
- Each imported name from this _module namespace clone_ would need to be a primitive or a wrapped callable object.
- Each imported callable object would lose references to the extra properties in the original callable objects.

For most of the Realms use cases, relating to controlled execution of a code inside a child realm, you can rely on communication channels which can translate to a few functions. 

The other ideal, which I believe match your concerns, would be a direct access to the imported module namespace. That's actually part of the previous and "original" Realms proposal, where we had a `Realm.prototype.import('specifierString')`. Unfortunately, this is a constraint for implementers and we couldn't move the proposal ahead this way.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/542#issuecomment-841368017

Received on Friday, 14 May 2021 16:49:07 UTC