►
From YouTube: SES Meeting - Compartment Options Bag
Description
Kris Kowal presents recommendations for the TC39 Compartment module loader proposal, like a constructor options bag.
A
A
B
B
A
According
the
november
16,
where
yeah
there's
a
there's,
a
list
of
announcements
at
the
top
of
the
agenda-
and
I
do
not
know
who
contributed
them,
but
according
to
this-
oh
yes,
the
sixth
right,
the
next
meeting
on
the
16th
agent.
Yes,
thank
you,
okay,
cool!
So
we'll
we'll
have
a
bit
of
a
break
and
then.
C
A
A
All
right,
I'm
not
okay.
So
the
eve
of
thanksgiving
I've
proposed
that
we
talk
about
the
topic
that
dan
ehrenberg
suggested
for
module
blocks,
which
will
be
fun
because
module
blocks
were
in
the
original,
simple
modules
proposal
and-
and
it
looks
like
we
do
not
have-
we
do
not
have
confirmation
from
our
of
from
surma,
but
we
can
follow
up
on
that
dan.
If
surma's
not
available.
Would
you
like
to
still
pursue
this
topic
in
two
weeks?.
C
B
A
Okay,
cool,
let's
so
tentatively
planning
for
november
25th,
to
talk
about
module
blocks,
and
we
do
have
confirmation
from
from
multiple
invited
experts
that
they
would
be
available
to
talk
about
hot
module
replacement
on
december
2nd
and
that's
evaluator
module
attributes
because
it
can
be
can
reinterpret.
Modules
was
also
a
side
topic
that
I
propose
that
we
discuss,
and
for
that
we
would
need
you
dan.
Is
that
all
right,
sound
good.
D
A
Okay,
cool
and
then
we
had
a
from
salesforce
charles
vaughan
would
be
available
to
talk
with
us
about
the
co
coherence
between
web
assembly
and
content
security
policies,
and
he's
confirmed.
So
this
would
carry
us
through
most
through
mostly
most
of
the
year.
Does
this
does
this
agenda?
Does
this
set
of
agendas
for
the
upcoming
meeting
sound
good
to
everyone
here?
Are
there
any
objections?
A
A
C
Probably
less
than
that,
unless
we
have
questions
thanks
for
allowing
me
to
add
this,
such
in
a
short
notice,
but
first
of
all
I
like
to
share
this.
I
just
received
my
ecmo
award,
I'm
so
glad
yeah.
This
thing
is
heavy.
I
just
received
it
from
the
from
the
mail,
but
talking
about
rounds,
I
discussed
with
caridi,
and
we
should
be
tentatively
going
for
stage
three
at
this
dc-39
meeting
and
this
in
november.
C
There.
There
are
things
that
are
not
like
as
ready
as
I
wanted
them
to
to
be,
but
I
think
we
have
enough
of
new
information
and
feedback.
I'm
gonna
try
to
summarize
some
of
them.
We
identified
some
prior
art
for
usage
of
realms
like
in
va
for
android
those
use
realms.
It's
probably
the
same
thing
powering
there
is
powering
nodejs
vm.
C
C
And
basically,
those
shows
like
some
prior
art
being
used
already,
for
there
is
basically
similar
to
what
we
want
for
realms.
We've
had
some
feedback
I've
I've
had
a
somehow
neutral
feedback
from
zela,
but
it's
more
in
sort
of.
If
we
go
with
roms
they're
positive
to
to
go
with
it
as
well
they're
neutral
in
a
sense.
Yes,
they
they
will
be
on
the
same
page
if
we
actually
go
for
stage
three
without
that,
also
I'm
not
blocking
it
at
any
point.
C
I've
got
some
similar
feedback
from
webkit
in
in
the
terms
of
it
it
works
for
them.
It
doesn't
have
anything
outstanding
to
for
us
to
get
our
attention
into,
or
that
would
be
a
problem.
This
is
the
the
best
sense
that
we
can
get
from
from
webkit.
In
terms
of
like
we,
we
cannot
tell
what
is
going
to
be
in
the
airplanes
and
it's
fine.
I
think
those
are
positive
from
the
chrome
perspective.
C
C
The
last
thing
that
I'm
doing
I'm
syncing
directly
with
shu
from
v8
on
monday,
just
to
make
sure
I
think
shoe
is
a
last
point
that
we
need
to
make
sure
like.
We
are
good
to
request
for
stage
three.
Hopefully
it
will
go
nice
at
least
to
to
give
it
a
try
and
to
give
it
a
report,
I'm
just
starting
now,
because.
C
C
There
is
already
available
in
engines,
and
I
think
I
am
satisfied
with
the
use
cases
like
the
the
list
of
use
cases
that
we
have.
We
have
many.
We
have
plenty
of
use
cases,
it's
not
a
common
use
case
for
some
browser
developers,
as
some
of
them
pointed
out
like
they
don't
they're,
not
gonna
use
that,
but
it's
we
have
plenty
of
use
cases
for
the
web
dev
reality
and
even
for
other
companies
like
such
as
google
like
the
amp
team
would
definitely
use
realms.
C
C
C
A
All
right,
so
this
is
pretty
self-explanatory,
but
I'll
go
through
it
anyway.
At
the
moment,
the
compartment
as
specified
today
takes
three
positional
arguments,
all
of
which
are
optional,
one
of
which
is
an
options
bag,
and
I
would
like,
I
think
it
would
be
good,
even
though
there
are
few
precedents
for
constructors
in
the
language
that
only
take
an
options
bag,
because
all
of
their
parameters
are
optional
to
to
move
in
the
direction
of
having
a
single
options
bag.
A
A
B
B
The
critical
group
to
get
feedback
from
on
this
is
modelable
because
they
already
implemented
a
because
they
already
implemented
the
other
one
and
b
when
we've
suggested
this
to
them
before
they
were
resistant.
So
they're,
the
only
that's
the
only
resistance
that
I
know
of
to
moving
to
a
completely
name-based
api.
For
this,
the
other
feedback
here
is
turning
endowments
into
globals.
I
like
turning
global
lexicals
into
the
locals.
I
hate.
B
E
B
B
E
B
E
Suggest
I
I
think
we're
saying
the
word
global
is
a
prefix,
and
then
we
can
contrast
what
is
lexical
versus
whatever
the
most
appropriate
contrast
word
for
that,
so
so
global
x
versus
global
y
and
the
two
the
two
make
sense,
because
one
of
them
is
different
from
the
other
but
they're
both
functionally
the
same.
If
you're
writing
code.
B
E
A
Yeah
yeah,
this
feedback
is
excellent.
I
think
that
the
the
main
point
of
this
slide
is
that
I
that
I
would
love
to
have
an
options
bag,
and
I
consider
I
can
and
we
just
need
to
get.
We
need
to
have
that
conversation
with
audible
present
the
the
specific
names
of
these
things.
We
can
continue
and
the
semantics
of
these
things
we
can
continue
to
discuss
independently
yeah.
E
D
D
A
Global
lexicals
certainly
are
need
to
be
looked
up
once
because
they
construct
constants
in
scope
of
modules
and
evaluation,
the
the
globals
we
can
continue
to
debate,
but
at
the
moment
at
the
moment,
the
ship
that
says
shim
assigns
them
to
global
this.
Inside
of
the
constructor,
it's
actually
kind
of
an
unnecessary
api.
B
D
B
D
B
Okay,
I
think
that's
an
argument
we'll
need
to
have
one
of
the
things
is.
If
you
look
it
up
once,
then
you
can
make
you,
then
you
well.
This
applies
more
proxies
than
this
opportunity
than
it
does
to
compartment,
but
I
think
it's
true
for
both.
If
you
look
it
up
only
once
then,
when
you
see
the
absence
you
can
optimize
for
the
absence,
if
it
always
might
appear,
and
then
you
have
to
treat
it
like
it's
there,
then
you
can't
opt
then
there's
certain
optimization
opportunities.
You
cannot
realize.
A
Yeah
and
if
we
end
up
if
this
ends
up
being
a
handler
object,
it'll
obviously
have
to
we'll
have
to
be
very
clear
about
when
it,
when
we
call
methods
of
our
access
properties
and
call
methods
of
that
handler
object,
because
there
is
no
sensible
lazy,
binding
for
name
globals
or
global
lexicals,
but
even
the
module
map
there's
no
sensible
use
of
it
post
construction,
but
I
could
see
them
I
could
see.
I
could
see
the
resolve
hook,
load
hook
and
module
map
hook
as
having
method
semantics
on
the
handler
object.
B
A
D
D
B
So
I
think
I
think
that
for
this
conversation,
I'm
getting
that
there's
a
very
coherent
way
to
explain
why
this
is
an
options.
Bag
and
not
a
handler,
which
is
this
is
really
about
configuring.
The
compartment
on
instantiation,
it
is
not.
It
is
not
primarily
about
the
dynamic
behavior
of
the
compartment
once
instantiated
and
in
that
regard,
it's
completely
different
than
the
proxy
handler.
The
proxy
handler
is
all
about
what
it
does
on
each
trap.
B
A
Yeah
yeah,
notably,
it
would
introduce
the
expectation
that
the
module
map
would
be
modified
by
the
module
system
itself
so
that
it
could
be,
you
know,
have
produced
some
observable
state
about
the
loader,
which
we
definitely
would
not
want
to
reveal.
No
anyhow,
okay.
So
I'm
going
to
I'm
going
to
proceed
on
the
on
the
assumption
that
this
group,
at
least,
has
enjoys
the
idea
of
of
altering
the
proposal.
In
this
way,
there
are
some
logistical
problems
of
moving
forward
with
with
compatibility
both
for
the
session
and
for
excess.
A
A
I
had
not
expected
that
part
of
the
rationale
for
boxing
the
proxied
exports
in
this
promise
was
that
there
was
a
possibility
of
having
other
of
introducing
additional
data
apart
from
the
module
exports
namespace
on
that,
so
in.
In
short,
I
am
proposing,
and
I
still
feel
strongly
that
it
would
be
great
if
we
could
alter
the
specification
such
that
dynamic
import
returns,
the
proxy
to
exports
wrapped
in
a
promise
directly,
and
I
open
it
to
discussion
in
this
venue.
D
D
Historically,
we
were
using
the
return
value
actually
from
modules
and
we
were
using
the
name
space.
Those
were
two
major
datum
due
to
top
level
of
weight.
We
can't
reliably
use
the
return
value
of
modules,
which
is
complicated,
because
if
you
have
a
top
level
of
weight,
you
always
get
undefined,
not
what
you
might
expect
as
a
completion
value.
D
D
Types
so
yeah,
so
those
were
the
two
main
datum
that
we
were
trying
to
get
out
of
it.
The
other
thing
is
we
needed
to
know
that
the
module
namespace
of
what
we
were
attempting
to
import
was
not
an
unexpected
value,
then
able's
don't
guarantee
that
you'll
even
get
a
export
back,
so
the
proposed
has
the
wrong
return
type.
A
D
B
D
B
B
Well,
wealth
is
still
around
the
module
itself
as
a
whole
gets
garbage
collected,
then
fine,
but
if
the
module
itself
is
not
garbage
collected
and
it's
possible
also
import
meta
is
a
special
form,
so
you
can
tell
lexically
whether
or
not
it's
possible.
The
engine
can
tell
whether
it's
possible
for
that
expression
to
be
evaluated
again,
once
it's
not
possible
that
the
expression
gets
evaluated
again,
that's
great,
that's
grounds
for
garbage
collecting,
but
until
then
it's
just
not
garbage
it
should
not
be.
B
D
A
A
B
E
A
B
Well,
I
mean
just
the
other
principle
that
we've
generally
followed
applied
consistently.
Here
I
can't
say
I
like
this
would
be
that
we
we
rename
the
constructor
in
questions
something
other
than
compartment,
because
compartment
itself
and
their
implementation
is
already
associated
with
an
incompatible
api
and
there's
no
way
to
feature
detect,
which
call
is
happening.
A
Yeah
that
might
be
necessary,
I'm
not
jazzed
about
renaming
compartment,
but
we
could,
if
we
had
to
all
right.
The
last
topic
is
wedi
and
and
not
well
formed,
but
I
bring
it
up
because
it's
an
issue
that
is
on
the
horizon
for
us
at
agoric,
and
that
is
the
compartments-
are
very
compartment.
Constructors
are
very
interesting
and
special
in
the
sense
that
they
are
meta,
constructors
and
or
at
least
they
they
have
where
the
implementation
needs
to
be
able
to
construct
new
constructors
for
every
compartment.
A
So
if
you
instantiate
new
compartment
within
that
compartment,
there
will
be
a
global,
this
dot
compartment
constructor.
That
is
different
than
the
parent.
That
being
the
case,
it
may
become
necessary
it
well
it
almost.
It
is
certainly
necessary
for
agorax
use
cases
that
we
expose
from
our
shim
some
vehicle
for
constructing
compartments
as
compartment
constructors.
A
B
Any
case
a
question
go
since
the
constructor,
since
the
compartment
constructor,
as
you
say,
is
already
a
meta
constructor
in
that
it
constructs
new
compartment
constructors,
anything
that
you
can
do
with
this
new
level.
Couldn't
you
do
by
adding
a
hook
to
the
options
bag
and
just
still
just
having
a
compartment
constructor,
where
the
hook
has
to
do
with
conditioning
what
kind
of
compartment
constructors
that
compartment
creates.
B
A
A
To
to
alter
the
compartment
constructor
itself,
in
any
case,
the
the
purpose
of
this
feature
for
agorax
case
is
that
we
have
the
need
to
adapt
our
compartment
constructors
such
that
they
have
certain
inescapable,
transforms
and
inescapable
intrinsics,
that
is
to
say
that
if
you
create
a
compartment
with
a
metering
transform
that
ensures
that
your
code
is
metered
and
and
and
a
global
lexical.
That
is
the
meter
that
needs
to
be
realized
for
any
of
your
transitive
compartments.
B
Let
me
make
two
quick
points
about
this.
One
is
eatering
case
is
unusual
because
in
general
we
don't
have
a
need
for
this,
because
the
default
is
that
a
compartment
creates
a
powerless
environment
unless
endowed
and
therefore
the
need
to
transitively
reduce
power
doesn't
usually
arise,
because
it's
already
starting
off
powerless
metering
reveals
that
what
we
mean
by
powerless
in
general
does
not
include
limiting
compute
resources.
So
that's
a
additional
reduction
in
power
that
we
don't
normally
talk
about.
B
The
other
thing
I
want
to
mention
is
that
realms
have
so
far
avoided
talking
about
host
hooks
at
the
realm
level,
because
of
the
assumption
that
or
not
the
assumption,
the
negotiated
compromise.
That
compartments
would
also
create
a
new
realm
constructor
and
that's
a
compromise
I
want
to
revisit.
I
don't
think
that's
the
right
way
to
do
that
so,
but
so
I
just
want
to
put
that
on
the
table.
A
Let's
briefly,
re-go
over
the
announcement
we
made
before
we
began
recording
since
salah
had
follow-up
question
that
was
that
regards
so
ses
shim
just
landed
just
we
just
released
a
version
of
the
sgm
that
has
that
allows
us
to
transport.
The
error
stack
to
the
console
without
revealing
it
to
anybody
who
catches
the
error
and
salah
had
a
follow-up
question.
I
believe
about
how
we
go
about
that
or
details
about
what
we
ended
up.
E
B
So
the
so
this
is
actually
what
we're
doing
is
very
much
along
the
lines
of,
but
currently
a
subset
of,
the
error
stack
proposal
where
there's
a
some
powers
that
are
part
of
the
post
lockdown.
There
are
powers
that
are
added
to
the
start.
Compartment
globals,
but
not
added
to
the
default
globals
of
new
compartments
called
get
stack
and
get
stack
string
to
take
an
error
object
as
an
argument.
E
Okay,
that
that
sounds
good,
just
a
follow-up,
tangent
there's
also
a
source
mapping
url,
I
think
which
allows
you
to
shadow
in
some.
You
know
some
code
that
works
and
other
code.
It
doesn't.
I
think
it's
because
you
know
the
implementation
is
not
standardized,
so
has
source
mapping
urls
been,
I
guess,
factored
into
the
design
or.