►
Description
Wherein, we review the new Compartment API improvements in XS.
A
B
A
In
the
past,
like
the
module
function,
compartment
module
function
and
such
and
the
first
notable
divergence
is
that
the
static
module
record
instead
of
accepting
the
source
string,
accepts
a
record
containing
the
source
string,
which
is
a
superficial
and
we'll
just
talk
about
that
next
week.
But
the
the
interesting
one
is
for
a
third-party
module
record
there.
A
The
difference
is
that,
instead
of
just
returning
the
third-party
module
record
itself
in
a
load
hook,
it
must
be
constructed
with
the
static
module
record
wrapper,
which
is
probably
a
sensible
thing
for
a
native
engine
to
require
and
the
the
difference
there
is
that,
instead
of
a
source
string,
you
send
a
list
of
bindings
and
an
initialize
function.
This
is
very
similar
to
what
we're
proposing
for
third-party
static
static
module
records
in
the
in
the
session.
A
As
we've
implemented
in
the
session,
the
difference
is
that
this
bindings,
this
closely
resembles
what
would
be
parsed
out
of
the
source
of
a
static
module
record
which
is
nice.
This
is
this.
You
could
easily
see
scanning
statically
analyzing
the
text
of
a
static
module
record
and
producing
this
array
that
this
means
there
was
an
import
statement
at
some
point,
and
this
was
just
an
export
statement
or
not
even
a
statement.
A
These
are
decomposed
from
the
d
structures
of
a
of
a
single
statement,
and
this
allows
the
allows
you
to
express
imports,
exports
and
re-exports.
I
think
it's
just
transposed
in
a
different
way
than
what
we
have
in
in
our
implementation.
I
think
that
this
is
just
work
to
get
converged
on.
I
don't
think,
there's
anything
existential
on
it
and
whether
we
converge
with
them
or
they
converge
with
us.
I
think
it's
fine
either
way.
Do
you
have
any.
A
Yeah,
it's
shim
says
it's
an
array
of
the
module
specified
the
import
module
specifiers
for
that
are
expressed
in
the
static
module
record.
It's
an
array
of
the
static
module
part
of
the
module,
the
the
import
specifiers,
there's,
there's
a
there's,
an
array
called
re-exports,
which
corresponds
to
export
star
from
import
specifiers.
B
A
Yeah,
I
might
my
my
intuition
is
that
in
that
case,
if
you
were
doing,
for
example,
a
bundler,
you
would
be
it
you
would
have
you
would
pre.
You
would
process
the
data
in
the
bindings
array
into
the
form
that
we're
already
using,
because,
ultimately,
you
need
to
get
the
list.
The
array
of
you
need
the
array
of
imports
and
re-exports
in
order
to
implement
a
bundler.
A
I
I
feel
so
yeah
all
right,
but
on
the
other
hand,
on
the
other
side
of
it,
if
you
were
implementing
something
that
does
static
analysis
on
some
other
module
format,
this
might
be
an
easier
place
to
stop
that's
sufficient
for
the
purpose.
It
just
depends
on
which
angle
you're
coming
from.
I
have
a
promise.
A
B
A
B
B
B
A
Gosh
common
js-
that
might
be
it
because
we're
using
common
js
for
third
party
yeah.
Here
we
go
so
this
is
the
common
js
static,
module
record
constructor,
which
doesn't
read
a
static
module
record.
It
creates
a
third-party
static
module
record
and
this
actually
is
quite
illustrative.
This
is
the
heuristic
analysis
which
produces
imports
and
exports.
A
Okay,
and
so
the
the
cgs
static
module
record
uses
the
imports
and
exports
obtained
by
the
heuristics
data,
static,
analysis
and
returns.
This
is
the
shape
of
the
third
party
static,
module
record
imports.
Exports
execute
now,
as
we
discussed
with
maudible.
We
want
to
rename
this
to
initialize,
because
that
is
closer
to
the
terminology
and
in
262.,
or
rather
I
do
feel
free
to
agree
or
disagree.
So
this
is-
and
this
was
my
name
choice.
So
it's
clear
this.
A
A
A
The
this
would
be
the
target
object
of
the
module
namespace
proxy,
which
means
that
or
maybe
not
even
the
target
object.
This
is
this.
Is
the
mutable,
the
controlled
interface
from
the
perspective
of
the
of
the
program?
That's
initializing
right
and
it
can
do
things
to
this
object
according
to
what
it's
the,
what
what
it's
expressed
for
its
exports
in
the
bindings.
A
So
this
is
an
object
whose
shape
is
determined
by
this
and
is
mutable
internally
in
ways
that
the
exported
that
the
module
namespace
object,
served
up
in
other
modules
would
not
be
it's
like
the
internal
view,
as
opposed
to
the
external
view.
They
also
pass
in
the
meta
object
which
we
have
not
implemented,
but
will
obviously
need
to
be
in
some
position
on
the
initialization
function.
A
The
the
resolved
specifiers
are
not
known
until
time
of
initialization,
so
so
there
are
a
few
things
that
we
need
to
converge
on
here.
One
is
that
we
ought
to
add.
The
meta
object
to
our
protocol
and
and
model
ought
to
add
the
compartment
and
the
resolved
specifiers.
Of
course,
they
don't
have
to
include
the
resolved
specifiers,
because
the
initializer
should
be
in
a
position
now.
No
they
should
they
should
they
really
should.
A
It
should
not
be
necessary
for
the
third-party
static
module
record
to
close
over
the
resolve
function
of
the
compartment,
that's
being
initialized,
and
it
should
be
portable,
so
yeah.
Those
are
the.
Those
are
the
big
things
here:
yeah
cool,
I'm
being
called
away.
So
I'm
going
to
leave
this
to
the
rest
of
you.
Thank
you.
Dan.
A
A
This
is,
this
is
illuminating
as
well.
They
make
it
the
initialized
function
that
they
provide
may
be
asynchronous,
and
if
it
is
asynchronous,
they
support
top
level
of
weight
during
initialization,
which
is
something
we
should
do,
but
do
not
at
the
moment,
that'll
require
some
restructuring
of
our
shims
internal
protocol.
B
Since
our
shim
is
a
shin
and
the
shim
yoshi
and
there's
already
some
things
that
the
shim
cannot
implement
reasonably,
that
a
direct
implementation
can
like
direct
direct
eval.
Maybe
the
you
know
at
this
point.
We
should
just
not
bother
investing
in
a
shim
implementation
of
top
level
weight
and
just
make
sure
ours
is
compatible
with
theirs.
But
then
just
you
know,
leave
it
to
them
to
to
implement
top
level
of
weight.