►
From YouTube: SES Meeting: Module constructor signature
Description
* What to do with import.meta.resolve
* Nested module blocks and combinations of module blocks and instances.
* Module constructor signature beyond Module(source, specifier, …) for importHook, importMeta, and beyond to account for import assertions.
** Resolution: tentative signature is new Module(source, importHook, referrer?, {meta?}?)
A
I
am
expecting
to
get
that
we
will
get
through,
possibly
two
of
them
we're
going
to
lead
with
a
question
I
have
from
for
the
group
about
what
to
do
about
the
section
on
the
intersection
semantics,
with
import
meta
resolve
in
the
layer.
0
explainer,
followed
by
karate,
having
an
update
for
us
to
make
sure
that
we're
all
on
the
same
page
about
how
module
blocks
and
module
instances
nested
within
each
other
work
and
how
import
hooks
get
inherited.
A
I
think
that
that
depends
upon
the
second
topic,
so
we
can
get
around
to
that.
Depending
on
on
how
things
settle
on
import
hook
inheritance,
the
question
is:
we've
set.
We
have
agreed
so
far
that
the
module
constructor
receives
its
first
two
positional
arguments
are
a
module
source
and
a
referrer
of
any
type,
and
the
question
is
what
to
do
about
threading,
the
import
hook
and
the
import
meta
and
how
to
leave
the
door
open
for
the
things
that
will
eventually
be
needed
to
support
import
assertions.
A
So
what
I'm
I'm
in
the
process
of
going
through
this
and
and
updating
it
to
match
what
we've,
mostly?
What
mark
and
carrity-
and
I
most
recently
agreed
upon,
which
was
that
the
import
meta
argument
of
the
import
hook
be
replaced
with
a
referrer
and
the
referrer
is
an
an
internal
slot
of
modules,
module
instances
and
can
be
of
any
javascript
value
type,
not
just
strings
and
that
it
is
sufficient.
A
It
closes
over
the
referrer
as
as
specified
for
the
web
and
in
what
wig
5572
now
guy
has
proposed
an
augmentation
to
the
import
meta
resolve
such
that
it
would
take
an
optional
referrer
and
be
suitable
across
import
hooks.
I
think
that
that
mostly
solves
the
problem,
but
it's
it's
still.
It's
still
fiction,
and
there
are
another.
There
are
other
ways
to
solve
the
problem
without
having
an
import
meta
threaded.
A
As
a
third
argument,
I
would
prefer
to
avoid
threading
import
meta
as
a
third
argument,
so
this
is
mostly
an
editorial
question.
I'm
assuming
that
we
want
that.
We
will
continue
to
want
import
hook
to
have
just
the
two
arguments,
specify
and
refer.
What
should
I
do
about
this
section?
The
most
compelling
at
the
moment
for
me
is
to
simply
delete
it.
If
that's
okay
with
everyone
else,.
B
B
B
Of
saying
hey,
you
still
can
use
these
in
the
web.
You
can
do
the
follow
the
result,
especially
for
modules
that
are
module
blocks
that
you
want
to
create
instances
to
do
a
specific
controls
of
the
of
the
module
resolution.
You
will
be
using
the
module
method
result
to
do
the
resolutions
related
to
the
the
module
itself.
A
Yeah,
so
having
a
case
that
does
use
import
better
resolve,
I
believe,
is
important,
because
import
meta
resolve
is
able
to
do
is
when
provided
by
the
host
is
likely
to
be
sensitive
to
things
like
import,
whereas
implementing
an
import
map
in
the
import
book
is
probably
not
good
in
overkill.
So
garrity,
if
I
read
your
counter
proposal
correctly,
are
you
suggesting
or
would
you
be
satisfied
if
I
simply
moved
this
import
hook
into
this
closure
such
that
it
uses.
B
I
I,
and
so
I
think,
even
the
arguments
instead
of
and
the
argument
of
the
input
hook
instead
of
getting
the
important
uppercase
method
there,
you
get
referral
right
and
then
in
the
following
line,
when
you
say
cons,
url
equal
import,
you
will
do
import.metadot
resolve,
specify
you
ignore
the
referral,
because
you
know
the
referral
is
going
to
be
the
actual
module
that
you
are
in
okay.
So
you
ignore
the
referral.
B
A
B
A
So
I
will
defer
the
question
of
whether
to
put
an
argument
back
until
after
the
next
topic,
but
I'm
satisfied
with
regard
to
what
to
do
with
this
example
is:
is
everybody
else?
Okay,
with
with
with
what
charity
suggests,
changing
this
to
import.meta
and
lighting?
This
argument,
for
the
purposes
of
this
example,.
E
B
My
my
conversation
with
nick
nicolo-
I
think,
he's
coming
back
this
week,
but
our
conversation
and
I
he
convinced
me
that
the
the
most
important
aspect
of
the
reflection
api
will
be
to
create
an
intent
that
is
ready
to
go
and
index
that
is
ready
to
be
imported
and
from
that
instance,
you
might
get
access
to
the
source,
but
the
source
might
be
no.
The
case
of
the
fs
modulus
node
you
get
a
source
that
is
null,
so
you
can
really
create
a
new
instance
out
of
it.
B
A
Right,
okay!
So
assuming
that
that
is
what,
assuming
that
that's
the
direction
that
folks
are
going
in
general.
That
is
good
news
to
for
the
answer
to
jack's
question,
and
that
is
that
nothing,
that
is
to
say,
if
we're
only
going
to
have
syntax
for
getting
module
instances
from
module
blocks
and
from
module
reflection.
A
A
Right,
it
just
means
that
the
source
syntax
would
be
a
shorthand
for
extracting
the
source
from
the
module
instance,
object
provided
by
the
import
hook
and
it
wouldn't
be
providing
the
performance
or
our
allocation
benefit
that
we
originally
discussed.
It
would
just
be
a
convenience
for
extracting
the
source
just.
A
E
What,
if
it's
not
only
about
source
of
a
module,
for
example,
I
can-
I
saw
some
very
expressive.
Example
in
the
imports
reflection
photo
that
imports.
For
example,
I
can
import
a
an
image
as
html
image
elements
or
as
an
arrow
buffer
that
also
reflect
reflect
to
the
same
underlying
resource,
but
I
reflect
it
into
different
types.
B
You
might
be
able
to
fetch
and
get
ready
for
usage
without
assuming
that
it's
a
source
of
a
a
source
text
module
where
the
intents
itself,
when
you
reflect
to
an
intent
or
or
do
anything
with
it
with
instances
as
they
are
right
now
specify
they
are
source
text
module
records
at
the
end
of
the
day,
and
if
it
fails
to
parse
it
fails
the
parse.
So
that's
the
primary
goal.
I
believe.
A
Asset
modules
should
be
solved
a
different
way
than
import
reflection.
The
there
there
are,
there
are
a
whole
bunch
of
ways.
Asset
modules
could
be
implemented.
I
think
that
it
is
a
non-goal,
for
I
think
it
is
a
non-goal,
at
least
for
some.
Somebody
is
likely
to
raise
the
point
that
it
is
a
non-goal
to
have
multiple
views
of
the
same
source
right
like
I'm,
going
to
write
a
css
file
that
coincidentally
parses
as
javascript
and
xml
or
whatnot.
It's.
I
don't
think
that
that's
going,
I
don't
think
that's
a
motivating
case.
A
Virtual
module
sources-
if
we
got
this
in
some
form,
not
necessarily
this
one
karate-
and
I
have
to
have
some
conversations
because
I
know
the
shape
of
this
is
all
wrong.
But
I
think
the
motivating
case
is
the
same
and
that
if
you
have
this
api
in
the
language,
then
you
don't
actually
need
anything
else
in
order
to
implement
asset
modules.
A
I
don't
think
that
it's
it
isn't.
It
isn't
even
necessary
or
useful
for
asset
modules
to
require
an
additional
syntax
on
the
import
side.
All
of
the
information
you
need
to
determine
that
a
dot
css
file
needs
to
have
different
execution,
behavior
and
a
particular
package
or
compartment
or
scope,
and
an
import
map
is
entirely
expressible
in
a
package,
a
scope
and
a
scope
of
an
import
map,
etc
and
doesn't
really
need
any
invent
extra
syntax.
A
B
Okay,
so
after
last
week,
when
we
have
discussions
about
some
of
the
apis
and
so
on,
I
did
the
changes,
but
also
make
a
little
bit
more
strides
on
the
resolution
and
some
of
the
missing
pieces
in
in
the
layer
zero
to
accommodate
module
blocks.
One
of
them
was
the
the
solution
for
nested
mojo
blocks,
which
is
an
interesting
thing,
and
so
the
current
semantic
that
we
have
there.
Basically
that-
and
I
can
probably
share
my
screen
here
and
try
to
find
that-
where
is
that
thing.
B
B
And-
and
there
might
be
some
issues
here
still,
but
this
is
preliminary.
The
idea
is
that
if
you
are
being
imported
by
module
and
that
module
happens
to
not
have
a
module
in
that
associated
to
it,
meaning
you're
being
imported
by
a
module
that
was
constructed
by
the
the
host
and
the
host
defines
the
before
behavior.
For
that
and
therefore
we
will
follow
through
and
we
will
basically
define
the
the
import
hook
as
a
default
behavior
of
what
the
hose
will
do,
which
is
basically
calling
this
api.
B
Regular
modules-
and
we
expand
the
layers
here
to
support
the
resolution
of
this
promise
to
be
an
actual
module
record.
This
is
a
new
thing
that
we
have
in
layer
zero.
So
now
the
import
hook
has
two
potential
overloaded
api
right
now
it
has
two
potential
results
could
be
that
you
resolve
to
a
module
linkedin.
It
could
be
that
you
resolve
to
a
module
record,
of
course,
in
user
line.
B
C
B
That,
obviously,
you
will
not
be
able
to
have.
You
will
not
be
able
to
construct
that
sorry.
You
will
not
be
able
to
hit
this
part
of
the
the
logic
for
nested
source
module
module
box.
You
will
not
be
able
to
hit
that
because
the
minute
you
have
a
module
created
by
a
browser
or
by
the
host
that
has
a
module
block
inside
that
has
another
module
block
inside
you
will
be
hitting
a
module
record
that
does
have
a
module
intense.
Therefore,
you're
gonna
jump
into
the
else.
B
So
this
is
only
a
if
you
are
a
a
module
block
declared
directly
in
a
module
that
was
instantiated
by
the
host.
This
is
the
only
only
scenario
where
you
define
that
otherwise,
you're
gonna
hit
this,
which
is
for
all
the
other
cases.
Where
you
have
no
referral.
You
have
a
referral.
That
is
not
a
module
record.
You.
C
D
B
Referral
that
is
a
module
record,
but
does
have
a
associated
module
intent
in
those
cases.
Then
what
we
do
there
might
be
some
issues
there
again.
I
realize
that
this
might
be
new,
so
we
have
to
be
careful
there,
but
the
idea
is
that
in
those
cases,
then
all
you
do
is
you
you
reuse,
the
the
the
import
hook
and
the
import
methods.
B
The
first
module
block
will
create
this.
The
second
one
will
inherit
this
input
hook
that
was
created
so
effectively.
There
are
equivalent
in
terms
of
behavior,
for
a
solution
of
dependencies
on
those
module
blocks.
You
don't
have
a
way
to
intersect
the
the
which
is
important.
You
will
not
be
able
to
intersect
the
resolution
for
that
kind
of
cases.
Where
you
have
the
host,
creating
a
module
that
then
you
use
a
module
block
to
create
a
nested
model
block.
You
have
no
ways
to
intersect
and
control
the
resolution.
B
A
B
B
That
this
condition
is
wrong,
but
I
I
can
make
it
better,
so
it
has
to
be
if
this
thing
exists
and
it's
a
modular
record,
and
so
I
I
have
to
make
something,
but
but
that's
pretty
much
it
these
are.
These
are
the
two
changes
that
we
did
since
last
week.
I
think
it's
important
that
we
put
together
some
examples
for
this,
for
people
to
understand
that
the
nested
blocks
will
work
just
fine,
but
I
didn't
want
to
change
the
explainer
to
to
highlight
this.
B
A
B
Still,
the
answer
to
that
is
no.
The
reason
why
it
is
no
is
that
imagine
that
you
get
a
source
and
you
from
that
source
you
create
a
new
intent
and
in
that
instance,
that
you
create
you
provide
on
hook.
Okay,
that's
the
case
that
you're
talking
about
that
correctly
yeah.
So
what
would
be
the
behavior
of
that
default
will
have
to
be
something
like
this
all
right,
like
the
default
behavior
of
the
browser.
Alright,.
A
So
my
my
what
I
am
imagining
is
that
the
module
constructor
as
an
object
has
an
internal
slot
for
its
the
execu,
its
corresponding
execution
context
in
much
the
same
way
as
a
function.
Constructor
does
and
the
execution
context
that's
associated
with
the
module.
Constructor
itself
should
have
an
import
behavior
associated
with
it
in
much
the
same
way
as
using
a
similar
out
that
they
can
be
defined
using
a
similar
algorithm
to
what
you're
proposing
here,
maybe
the
same
one
based
off
of
the
context.
B
B
A
B
E
B
A
B
A
B
E
E
B
Okay,
so
that
that
was
the
aha
moment
for
nicolo,
and
I,
when
we
were
talking
about
like
okay
well,
if
we
have
the
reflection
api,
then
you're
already
tapping
into
a
browser.
I
want
you
or
a
host.
I
want
you
to
resolve
this
euro
from
techno
to
the
place
where
I
create
a
module
and
you
can
do
import
on
it
with
a
reflection
which
returns
an
intent
and
is
a
this,
is
a
qualifying
result
for
the
book,
which
is
okay,
I'll,
say.
A
B
B
A
B
Okay.
So
I
think
that
that
that's
and
we
we
we
have
to
add
by
the
way
chris.
I
think
we
should
add
this
intersection
semantic
with
a
module
reflection
into
the
explainer
we
don't
have.
I
think
we
don't
have
that
section
the
file
here.
Why?
But
this
is
the
idea,
like
the
reflection,
will
give
you
the
ability
to
import
stuff,
get
it
ready,
isn't
it
done,
but
it
hasn't
been
evaluated
yet
yeah.
B
A
I
think
that
this
is
likely
to
end
up
looking
like
lazy,
true,
because
the
only
thing
about
this
import
that
is
different
than
a
normal
import
is
that
the
instance
returned
is
not
initialized
the
which
is
interesting,
because
that
means
that
this
is
going
to
this
okay,
no,
no,
no!
No!
This
is
in
this
is
intro,
so
dynamic
import
returns,
a
promise
for
a
namespace
object
right,
yes,
and
if
you
change
reflect,
if
you
change
it
with
reflect
true,
is
it
changing
that
the
signature
to
be.
B
B
B
B
C
C
A
B
A
A
B
B
You
could
think
about
someone
who
is
doing
an
import,
a
regular
import,
dynamic
import
on
a
specifier,
and
they
want
to
provide
their
own
methods
to
that.
So
independently
of
all
these
new
features-
and
it
seems
to
be
useful,
some
cases
special,
bundles
and
tools
that
want
to
collide
modules
and
then
do
something:
growth,
rollout
modules
and
so
on
you,
you
still
want
to
reflect
the
proper
metadown
to
those
two
modules
that
you're
about
reading.
So
you
have
a
hook
to
provide
a
meta.
B
If
you
provide
a
method,
it
must
be
an
octet,
otherwise
you
throw
the
nerve,
but
but
the
idea
is
that
we
can
make
this
a
generic.
So
you
can
do
assertions
you
can
do
methods
in
all
these
different
positions.
You
know-
and
that
seems
fine
to
me,
so
we
can
say
that
the
last
argument
is
optional
and
it's
an
option
back
that
contains
meta.
Contains
assertion
contain
all
all
these
other
things
that
we
might
need
to
be
able
to
open
up
for
people
to
control
virtualize.
B
A
B
B
B
It
is
not
going
to
be
your
own,
then
it
will
be
problematic
because
you
have
to
destruct.
You
have
to
pick
up
implementers.
You
have
to
also
pick
up
the
url
and
and
so
on.
So
if
we
settle
on
that
being
the
url
which
might
be
okay,
I
don't
I
don't
have
an
opinion
on
that.
Then
you
just
you
just
do
new
module
source
hook,
input
of
meta
now,
you're
gonna
really
put
it
like
that.
Yeah
yeah
yeah!
Yes,.
C
A
Yeah,
I
think
that,
having
leaving
it
positional,
even
if
it's
optional,
is
a
better
outcome
than
making
a
and
then
moving
it
to
an
options
bag
there
will
be
very.
There
will
be
very
limited
circumstances
where
it's
the,
where
the
right
thing
to
do
is
to
pass
null,
and
I
think
it
should
be
called
out
visually.
It
shouldn't
be
hidden.
B
B
B
C
D
Think
we
should
say
import
meta,
and
the
reason
is
that
meta
is
a
very
general
concept
and
this
thing
is
in
no
way
reflective
of
the
general
concept
of
metaness
and
some
you
know
something.
That's
reflector,
it's
a
reflective
of
something
at
some
deeper
level
might
very
well
want
to
use
the
term
meta
to
describe
something.
So
it
just
seems
like
it's
a
bad
word
to
describe
this
very
narrow,
narrow
and
non-meta-ish
concept.