archives

« Bugzilla Issues Index

#2490 — Clarify 'metadata' option property, esp. in Loader.prototype.define()


The current spec has
26.3.3.2 %Loader%.prototype.define ( name, source, options = undefined )
with this in the steps:

10.If metadata is undefined then let metadata be the result of calling ObjectCreate(%ObjectPrototype%).
11. Let p be PromiseOfStartLoadPartwayThrough("translate", loaderRecord, name, metadata, source,
address).

In implementing define() I found two issues here:
1) Must metadata be passed by reference to translate()?
2) What is the purpose of passing metadata here at all?

We have been using metadata as an opaque side-table for the loader hooks. The Loader provides the metadata object to each of the hook calls but does nothing else to the object. This way the hooks can add and remove properties for a Load object, confident that the data will arrive again with another call for the same Load object. If the metadata can be passed in from user code then all of that has to stop and we'll have to ignore the metadata property throughout the hooks calls.


> If the metadata can be passed in from user code then all of
> that has to stop and we'll have to ignore the metadata property throughout
> the hooks calls.

It can't be passed in from user code.

In some cases, the "load pipeline" starts in the middle, e.g. when you're doing loader.define(), you've already got the source code so that there's no point doing a locate() or fetch(). So no hook can assume the previous hooks were called. I think we just have to live with that. The ability to jump in at intermediate stages of a load is just too important a feature to drop.

For those in-medias-res cases, what should the metadata value be? We decided to create an empty object. I agree this is confusing and obnoxious. We considered some alternatives but didn't find anything clearly better. My best alternative was:

- Drop metadata from the spec entirely;

- instead, pass the *same* options object to locate, fetch, translate, and
instantiate;

- and then Loader hooks can store data on that object (attaching
whatever metadata properties they want, ad hoc).

I think that's more elegent, but is it really any better? Each hook that uses metadata would still have to detect the in-medias-res case and cope with it.


In our implementation, 'metadata' is a property of Load. That is how it appears in other functions of the spec API. There is no need to drop metadata from Load, or the rest if the spec. It's fine there, because Load is a data structure shared between the Loader and its hooks. The issue it having it part of the API for the define() function, a user level function, not a loader hook.

I'm confused by

>It can't be passed in from user code.

Loader.prototype.define() seems to be one of the primary user entry points. User code only really needs import() and define().


concerns old module spec.