►
From YouTube: SES Meeting: Module constructor with handler
Description
Wherein we discuss Caridy’s PR #78 that introduces a module handler object / options bag.
https://github.com/tc39/proposal-compartments/pull/78
A
Welcome
to
the
assess
meeting,
it
is
September
21st
of
2022.
This
is
the
first
meeting
after
the
Tokyo
plenary,
so
plenty
to
discuss,
but
first
off
congratulations
for
to
Nicolo
for
the
refactors
in
both
the
web
and
262
that
that
went
that
were
approved
at
plenary
last
week
with
with
no
objections.
It
was
wonderful
and
that
sets
us
up.
That
sets
us
up
really
well
to
make
progress
on
a
simpler
version
of
I.
A
Yes,
okay,
so
the
the
purpose
of
this
pivot
is
to
introduce
an
options
bag
to
or
not
an
options
bag,
but
a
Handler
object.
We
we
realized,
we
needed
an
options
bag,
at
least
as
the
second
argument
of
the
module,
Constructor
and
I.
Don't
know
if
we
have
a
a
summary
view
of
what
the
people
I
haven't.
Written
I
haven't
written
up
the
the
explainer
for
this
yet,
but
in
short,
it
looked.
The
module
Constructor
would
look
something
like
module
and.
B
A
Import
hook,
of
course,
and
that
would
receive
the
specifier
and
return
return.
A
module
instance
now
what's
changed
here.
Is
that
charity
realized
that
we
do
not
need
to
specify
the
referrer
as
a
second
argument,
if
referrer
is
an
expando
on
the
Handler
object
and
specifier
book
receives
this
much
in
the
way
that
proxy
handlers
receives
the
have
receive
the
context
or
the
receiver
object.
A
A
A
D
B
A
B
A
D
C
Some
things
that
I
that
came
out
when
when
I
was
doing
this
is
that
they
can
achieve
the
same
dynamic
aspect
of
the
proxies
with
this
API,
because
what
happened
is
that
you
can't
define
an
option
box
that
has
the
the
import
hook,
whose
job
is
to
just
do
it.
This
start
my
Dynamic
input
hook
and
then
you
can
change
that
value.
Dynamically
yep
yep.
A
C
D
There's
no
loss
of
generality,
which
is
why
the
mistake
we
made
with
proxies
was
you
know,
even
more
of
a
mistake
is
we
could
have
done
the
right
thing
without
losing
any
any
expressiveness,
but
so
yeah,
that's
great.
So
the
yeah
I
had
not
caught
that,
so
so
the
the
referrer
itself
just
does
not
appear
normatively
in
the
spec
at
all.
Is
that
really
that's
really
yeah?
There's
no
problem
with
that.
There.
A
A
To
that
extent,
I
agree
that
omitting
the
referrer
as
a
as
a
as
a
teaching
device
is
useful
and
I
think
that
that
does
inform
API
decisions
that
if
the
referrer
is
something
that
can
be
omitted
from
early
examples
of
the
API
in
order
to
avoid
confusing
the
reader
while
introducing
Concepts.
Incrementally
that
means
that
it
should
appear
in
places
where
it's
it
should
be
optional
and
if
it's
positional
it
should
be
last
and
to
that
part
to
all
of
that.
I
agree
with
karity,
where
omitting
it
from
the
API.
A
What
I
don't
love
about?
Omitting
it
from
the
formal
specification
is
that
I
do
not
feel
that
it
is
an
avoidable
concept,
that
any
practical
implementation
of
a
module
environment
will
need
to
mention
a
referrer
and
as
the
base
for
resolving
relative
Imports
since
every
environment,
almost
every
environment
supports
relative
Imports
and
not
having
it
mentioned,
not
having
it
mentioned,
gives
an
opportunity
for
it
to
have
like
10
000
different
names,
depending
on
which
implementation
you're
looking
at
reduces
shareability
and
that
kind
of
thing.
D
So
let
me
let
me
raise
then
two
possible
compromises
with
regard
to
how
we
were
the
spec
and
see
what
what
our
reaction
to
each
of
them
is.
One
is
that
we
simply
have
non-normative
text.
That
makes
it
very
clear
that
we
expect
a
referrer
whose
value
is
a
spring
and
whose
purpose
is,
as
stated,
the
the
other
compromise
we
could
make
is
to
go
ahead
and
actually
specify
it
as
a
optional
Pro.
A
I
think
I
would
be
satisfied
by
the
non-normative
form
and
actually
less
Satisfied
by
the
normative
form,
because
it
when
you
say
it
this
way,
it's
very
clear
that,
if
is
if
we
say
that
there
is
expected
to
be,
there
is
expected
to
be
a
referrer
property
and
it,
and
if
it
existed,
is
expected
to
be
a
string.
The
passive
voice,
turning
the
passive
voice
into
active
voice
tells
us
that
what
is
going
to
expect
it
is
the
user
provided
import
hook.
A
C
The,
but
before
getting
into
that,
just
to
note
on
the
prior
comment,
the
the
non-normative
will
be
will
have
to
be
very
hand
wavy,
because
this
referral
doesn't
have
to
be
in
a
string.
In
fact,
if
you
want
to
implement
a
A
or
or
virtualized
module
graph,
most
likely,
the
referral
will
be
as
it
is
in
262,
a
module
record
or
equivalent
that
you
have
to
a
module
record,
so
it
doesn't
have
to
be
in
a
string
by
any
means.
C
I,
don't
think,
that's
necessarily
something
that
we
have
to
add
there,
especially
because
you
never
really
do
anything
with
it.
It
really
doesn't
expect
I,
don't
expect
people
to
use
the
referral
to
be
honest,
they
they
they
could
be
doing
this
without
well.
Knowing
the
concept
of
referral
altogether.
A
C
B
C
D
B
B
The
HTML,
like
the
web
right
now
expects
the
referrer
to
be
a
very
specific
data
structure
with
some
info
and
well,
if
you're,
using
the
like,
if
you're,
creating
a
module
in
line,
we
are
not
attaching
this
specific
structure
to
the
model,
so
the
input
hook
has
to
fall
back
to
a
sun
like
default
Behavior,
because
we
cannot
communicate
the
referral
in
the
way
that
HTML
expects
it,
and
so
the
default
behavior
is
to
resolve
things
relative
to
the
web.
Page.
B
So
normally
specifies
a
result
relative
to
the
file
to
the
module
where
the
thing
is
imported,
with
a
very
specific
exception,
which
is
when
there
is,
which
is
when
you
have
a
dynamic
import
in
a
moment
where
there
is
no
active
module
or
an
active
script,
and
more
specifically
in
HTML.
That
can
happen
if
you
have
a
dynamic
import
in
an
event
handler
in
line
in
HTML.
B
However,
with
this
proposal
we
also
have
the
case
where
we
have
the
current
model,
which
is
a
module
we
had
it
in
line,
so
we
have
it,
but
it's
the
like
the
HTML
site,
never
sold
its
model,
so
do
not
have
this
chance
to
like
attach
its
information
to
this
model,
and
so
it
will
behave
the
same
as
having
no
like
from
an
HTML
perspective.
It's
the
same
as
having
an
active
model
when.
D
B
C
D
A
C
C
The
module
record
itself
and
the
module
record
is
the
module
record
that
we
create
for
these.
This
module
that
you
create
by
do
new
module
right,
so
we
provide
dial
intents
to
no.
No,
why
do
you
put?
Oh
so
the
the
assumption
that
I
make
in
the
pull
request,
I
so
and
I
was
intentionally
I'm
waving
there,
because
this
is
an
open
discussion.
Obviously,
but
what
I'm
doing
in
the
pull
request?
C
D
C
C
A
C
But
there
is
a
caveat
to
it.
The
host
has
to
do
some
work
and
that's
what
I
Define
here
so
Eve.
So
this
is
this
is
the
construction
path.
If
there
is
no
input
or
happens
to
be
undefined,
okay,
we
are
going
to
create
a
closure.
Basically
just
an
inline
function
that
in
life,
okay,
I'm
going
to
use
it's
going
to
expect
a
specified
parameter
to
be
passing
in
okay.
D
C
Already
captured
the
module
record
itself
that
we
are
creating
so
for
the
new
module,
we
create
a
module
record
and
then
we
create
an
instance
of
the
model
Constructor
right,
so
the
module
record.
We
keep
it
in
this
in
the
in
the
closure
as
part
of
the
concept,
so
the
and
then
we
Define
the
default
Behavior.
This
is
the
default
Behavior.
The
default
behavior
is
just
saying:
I'm
going
to
create
a
new
promise.
I
will
return,
promise
back
and
I
will
perform
something
on
the
host.
C
That
I
will
provide
the
module
record
of
the
module
that
I
just
created
and
the
promise
capability.
The
host
is
responsible
for
deciding
what
to
do
without
a
specifier,
for
the
module
record
that
we
are
providing
and
the
host
can
say.
Oh
I,
don't
know
this
model
record,
it
was
created
in
user
lab.
So
that
means
that
I
showed
you
the
page,
the
the
content
of
the
page
as
the
context
to
Define
how
the
specifier
should
be
resolved.
So
it's
content
of
what
page
the
page
in
which
this
this
module
is
being
created.
The.
A
D
C
So
the
the
idea
here
is
that
we
don't
prescribe
how
this
is.
Specifier
is
going
to
be
resolved.
We
never
prescribed
that
the
host
is
responsible
for
defining
that
we're
just
telling
them
the
host
hey
this
module
record
that
happens
to
be
created
because
someone
do
a
new
module.
This
is
the
module
record
for
it.
This
is
the
specified.
You
need
to
figure
out
how
to
resolve
things.
Resolve
this
promise
for
me,
and
and
that's
it
we
don't
we
don't.
We
don't
prescribe
different
hosts,
might
have
different
routes
for
that.
Okay,.
D
D
A
The
the
answer
to
that
is
that
The
evaluators
Constructor
receives
a
Handler
object
that
is
analogous
to
the
the
Handler
object
received
by
the
module
Constructor
and
in
the
re
and,
and
it
is
analogous
to
the
one
by
the
module
Constructor,
because
in
addition
to
constructing
a
new
intrinsic
function,
module
and
eval,
it
needs
to
associate
those
new
intrinsics
with
its
own
Handler
object
for
the
purposes
of
defining
the
behavior
of
dynamic
import
and
script.
Contexts
got.
D
A
D
D
A
C
C
And
so
on
the
same
line,
we
do
a
pretty
much
the
same
for
The
Meta
hook,
The
Meta
Hook
is
just
saying:
if
there
is
no
meta
hook,
then
this
is
an
evolved
metaphor
and
what
we
do
there
is
just
saying
host.
Tell
me
what
the
properties
should
be
for
this
module
record
and
I
suspect
that
most
of
the
hosts,
especially
on
the
web,
will
say.
C
Oh
this
module
record,
we
don't
know
much
about
it,
because
this
brand
new
we
never
seen
this
before
meaning
it
has
to
be
it
was
created
by
userline
and
I,
can
use
the
the
the
page
settings
object
to
decide
what
the
meta
should
look
like
for
that
particular
module
and
then,
from
that
point
on,
it's
just
the
creation
of
the
object
and
the
caching
of
that
object.
But
it's
the
same
principle.
I'll
say
that
we
just
don't
prescribe
what
to
go
into
that
meta.
We
tell
the
hosts
to
create
a
metaphors.
A
A
D
B
D
A
Yeah,
the
yeah,
the
custom
import
book
has
full
control
over
the
import
meta
because
it's
constructing
the
new
module
instance
that
does
bring
us
to
the
this
does
not
yet
address
the
the
import
meta
hook
that
or
whether
we
do
import
metahook
or
just
have
an
import
meta
object
on
the
or
or
both
so
I'm
I'm
not
paid
in
on
that
topic.
Yet.
C
D
So
so
so
hold
on.
There's
the
the
time
at
which
we
call
it
is
a
really
important
consideration
here.
There's
two
plausible
times:
one
is:
if
the
module
itself
has
an
import
meta
expression,
then
we
call
the
import
meta
hook
on
module
Construction
and
the
other
one
is
on
the
first
use.
I
prefer
that
we
just
do
it
up
front
on
module
Construction
because
doing
it
on
first
use
is
I.
Don't
know
that
it's
it's.
D
D
Interleaving
there
of
user
code
during
the
access
to
the
import
meta
object.
The
evaluation
of
the
expression
is
an
issue
to
be
concerned
about,
but
I
don't
know
that
it's
not
an
issue
to
be
concerned
about,
but
I
know
that,
if
we're
doing
it
at
construction
time,
we
still
have
the
important
optimization
that
the
vast
majority
of
modules
never
mention
import
meta,
and
then
we
avoid
calling
the
hook
for
that
vast
majority
of
modules
and
the
tiny
number
of
modules
that
mention
it
and
never
evaluate
it.
I
don't
care
to
optimize
those.
C
D
C
Yeah
yeah,
you
know
even
yeah,
so
you
you
do
evolve
and
in
that
eval
you're
doing
some
creation
of
a
module,
a
Blog
in
there
the
the
module
itself
will
call
the
hook
because
it
will
inherit
the
hook
and
and
now
it's
the
hook
will
be
called
later
in
time,
not
during
construction,
because
you
didn't
know
about
up
front.
So
that's
the
only
thing.
A
D
A
C
C
D
C
C
And
then
the
the
other
thing
is
that
there
might
be
other
apis
like
they
import
reflection
or
some
sort,
which
we
have
an
exploring
in
details
that
the
the
Mind
need
to
inherit
the
hook
from
the
places
where
you
do
the
import.
And
if
that's
the
case,
then
there
are
scenarios
in
which
you
have
to
determine
that
the
eager
creation
of
the
meta
object
has
to
be
has
to
happen.
D
Okay,
so
so
you're
right,
the
the
reflection
thing.
Obviously,
we
need
to
understand
the
implications
from
that
and
right
now.
What's
in
our
stance
on
reflection,
is
that
the
result
of
doing
a
you
know,
static,
import
law
or,
however,
it
is
that
we
need
to
work.
The
reflection
gives
us
something
that
doesn't
does
or
does
not
have
a
metabound.
D
B
So,
even
if
it
has
it's
not
a
problem
because
like
when
you
see
the
import
reflection
statement,
you
call
the
import
and
the
import
hook
gives
you
a
Model.
A
module
object
with
some
like
metadata,
and
we
just
return
that
model
objects
as
it
is
without
actually
evaluating
it.
Yet,
however,
that
object
has
all
the
hooks
all
the
contacts
that
we
need,
and
so,
when
we
later
evaluate
the
the
reflection
object,
we
call
all
the
hooks,
and
it
already
has
all
the
metadata
that
it
needs.
A
The
import
import
reflection
is
going
to
produce
an
instance
of
a
module
object,
that's
backed
by
a
module
record
and
therefore
contains
all
of
the
all
of
the
the
import
meta
information
the,
but
it
also
contains
a
static
module
record,
which
is
not
that
does
not
capture
a
module.
Source
object,
which
is
backed
by
a
static
module,
Source
record
I,
think,
is
what
we're
calling
it.
A
C
There's
another
thing
that
I
just
just
occurred
to
me
and
that
might
be
interesting
to
explore
and
most
most
likely
vitalization
for
a
musical
on
this
one.
If
I
have
a
module
that
runs
on
a
page
and
it
has
a
import
meta
that
happens
later
in
time.
So
I
have
a
function
that
we
call
it
using
for
meta
for
the
first
time
for
that
module
even
before
I
call
that
module
I
push
a
new
URL
to
the
to
the
current
page
and
then
I
call
the
meta.
C
C
The
page
you
navigate
the
page,
but
without
navigating
because
it's
the
same
route,
it's
just
you
just
change
the
url,
the
base
URL
the
page,
and
now
you
access
the
meta
at
that
point.
What
would
be
the
value
and
I?
Don't
know
what
the
whole
Behavior
would
be
because
I
don't
know
if
they
are
eagerly
creating
these
ignoring
what
he's
going
to
expect
special.
B
C
B
C
B
C
B
B
D
B
D
D
D
In
I'm
interested
in
minimizing
the
amount
of
discretion
hosts
have
and
and
having
the
262
spec
create
as
much
Universal
agreement
among
hosts
as
we
can
get
the
existing
hosts
to
agree
to,
and
if
this
is
not
and
the
only
hosts
that
it
put
that
generally
put
up
a
fight
or
the
HTML
hosts.
So
what
we're
specifying
already
agrees
with
the
behavior
of
the
HTML
hosts
I
think
we
can
be
more
specific.
We
can
take
this
discretion
away.
D
A
That's,
that's
not
how
it
plays
out
you.
The
choice
is
actually
between
providing
an
import
book,
an
import
meta
hook
or
providing
an
import
meta.
If
you
do
provide
an
import
meta,
that
means
that
you
have
to
have
more
reflection
on
the
module
Source
API
in
order
for
import
books
to
provide
the
behavior
that
they
need
to
have
right,
because
we've
previously
discussed
having
a
needs,
import,
meta
property
on
module
sources
that
would
be
necessary
if
we're
eager.
It's
not
necessary.
If
we're
ad
hoc.
A
That
there
are
two
paths,
one
of
which
is
eager,
which
is
lazy.
What's
eager
is
the
case
where
the
import
meta
must
be
constructed
at
the
time
of
module
construction
or
provide
the
module
if
the
module
Source
declares
that
it
is
needed,
okay,
right
and
then
the
lazy,
the
lazy
one
is
where
there's
an
import
hook
on
the
module
on
the
module
Handler,
which
is
called
at
the
time
of
the
first
evaluation
of
an
import
meta
expression
in
that
module
right.
D
So
so
so
I
think
there's
there
there's
the
first.
The
eager
case
divides
up
into
into
two
cases
that
that
I
think
is
the
source
of
my
confusion.
There's
you
have
to
provide
an
import
meta
object.
If
the
module
says
it
needs
one
or
you
provide
a
a
import
meta
hook
that
does
or
does
not
get
called
on
construction
depending
on
whether
the
module
is
you
know,
statically
might
need
one
or
not.
Okay,.
A
D
Seems
that's
the
one
that
seems
simplest
to
me,
so
you
don't
need
you
don't
need
a
separate
needs
meta
flag
on
the
module
source.
It's
just
that
the
hook
does
or
does
not
get
called
at
construction
time.
The
user
of
the
API
can
always
just
provide
the
hook
and
then
not
construct.
The
Meta
object
if
the
hook
never
gets
caught
and.
A
I
think
I
understand
what
you're
suggesting
is
that
the
module
Constructor
itself
on
its
own
stack
would
call
the
import
meta
hook
if
the
mod,
if
the,
if
the
module
Source
also
given
to
the
module
Constructor,
has
effectively
at
and
needs
import
meta
property
on
it.
But
it
can
be
an
internal
slot
in
this
design.
Instead
of
being
a
public
property.
D
C
C
B
I
want
to
check
if
everyone
agrees
with
me
on
the
fact
that
JavaScript,
like
username,
like
this
modus
API,
should
be
exactly
as
powerful
as
the
host
hooks
like
API
Expo
structural
hosts,
because
I'm
like
we
are
discussing
some
things
which
are
different
from
how
hot
socks
behave.
So
I
think
that
if
we
want
to
restrict
or
give
more
power
to
the
JavaScript
API,
we
should
also
restrict
or
give
more
power
to
the
host
hooks.
I.
A
I
think
if
I
understand
Mark's
position,
I
think
that
I
would
say
more
I.
Think
I
would
say
that
we
would
like
both
the
host
Hooks
and
and
the
virtualized
host
hooks
to
provide
the
same
expressiveness,
and
we
want
to
limit
that
expressiveness
to
what
is
necessary
for
existing
engines
and
provide
no
more
powers
and
existing
engines
need.