Mutable slots/indirect value API
IOW expose the first-class "reference type" of ECMA-262 via a standard library? Just say no! :)
First, the module function API is written up wrong on the wiki; the function won't take any arguments at all. My apologies, I discovered my mistake as I was working on the spec writeup in the last few days. I'll be updating the wiki as soon as I complete the draft spec.
Here's how cycles work. An AMD compatibility layer would simply use the dependency list to look them all up in the loader to pass as arguments to the AMD module-function. Any dependencies that are not there yet are assumed to be forward references in a cycle, and the compatibility layer synthesizes new exports plain-old-objects to pass in to the AMD functions. (BTW we'll be building proof-of-concept AMD compatibility layers to demonstrate that this works.)
BTW, this whole module-function rigamarole only exists for AMD compatibility, so it's only important for it to demonstrate interoperability. For normal ES6 use cases there's just no need to use it.
On Sun, Nov 3, 2013 at 12:34 PM, David Herman <dherman at mozilla.com> wrote:
IOW expose the first-class "reference type" of ECMA-262 via a standard library? Just say no! :)
I was thinking that if they were used anyway by the module system, formalizing them might help, the "provide the primitives" sort of API design. I am sure that kind of consideration is probably quite a bit of work though (sounds like scary too from your response), so sorry for the distraction.
BTW, this whole module-function rigamarole only exists for AMD compatibility, so it's only important for it to demonstrate interoperability. For normal ES6 use cases there's just no need to use it.
I was not asking about it related to AMD compatibility. AMD's cycle support is not that strong, so this capability would not be used specifically for AMD conversions, as that concept is not possible now with AMD.
This came out of wanting some other way to inline multiple ES-type of modules in a file, without needing to rely on the JS-strings-in-JS that were mentioned in the previously mentioned thread. The thought of being able to use a function instead was appealing, but wanted to be sure a similar cycle support to ES modules could work in that format. Not an exact match for true import/export syntax, but may be good enough for single, default export type of modules.
I will try to wait until the later November design artifacts are done before asking more questions.
With the import/export mutable slots concept, does it make sense to allow an API that has expresses that type of concept? I think it would allow creating a module-function thunk that would allow robust cycles as mentioned here:
esdiscuss/2013-November/034576
So something that returns a value, but when it is looked up by the engine, it really is just an indirection to some other value that can be set later. Call it IndirectValue for purposes of illustration, but the name is not that important for this message:
var value = new IndirectValue(); // something is a kind of "ref to a ref" engine type under the covers var something = value.ref(); typeof something === 'undefined' // true at this point // Some time later, the code that created the // IndirectValue sets the final value for it. value.set([100, 200]); // Then later, Array.isArray(something) // true nowIndirectValue.prototype.set()could only be called once, and the engine under the covers could optimize the indirections after theset()is called so that the indirection would not longer be needed.