►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
B
B
B
And
that's
this
interface
well
part
of
this
part
of
this
part
of
the
interface
that
is
represented
by
this
type
signature
here,
there's
a
create
to
create
a
new
virtual
machine
and
there's
a
corresponding
restore.
If
you
want
to
restore
one
but
that's
not
covered
here
and
and
then
there's
a
this,
is
global.
This
you'll
see
that
the
snap
sounds
very
familiar
to
the
compartment
API
for
accessing
a
the
Global's
and
in
this
case,
because
it's
an
actual
virtual
machine
outside
of
large
the
global.
B
This
is
a
is
a
proxy
of
of
that
of
the
proxy
whose
properties
are
the
global
variables
on
in
the
in
the
virtual
machine
and
and
in
the
key
parts
that
I
wanted
to
talk
about.
For
the
modules
is
this
important
l
method
and
there's
a
there's
a
corresponding
hook,
but
the
hook
is
not
provided
in
the
create.
So
that's
this
one
of
the
one
of
the
fundamental
differences
between
the
two
api's
well.
A
B
B
B
What
I'm
calling
a
module
source
which,
which
is
an
object
that
contains
the
source
text
and
some
other
stuff
which
I'll
get
see
and
it
produces
a
module
object.
So
this
is
quite
different
to
the
compartment
API
compartment
API
import
now
accepts
a
specifier
and
the
way
that
returns
the
module
object
in
in
the
case
of
micro
VM.
The
what's
given
is
actually
a
representation
of
the
source
text
and
it's
is
literally
the
source
text.
There's
no
there's
no
module
stamp
record
or
anything
like
that.
I'd.
A
Method,
name
that
is
defined
with
a
particular
signature
and
a
particular
semantics
in
one
of
the
things
that
are
in
that
general
functionality
space
that
a
method,
another
method,
that's
in
the
same
general
area,
but
with
very,
very
different
type
signature
yeah
significantly
different
semantics-
should
have
a
different
name
if
I
I
would
find
it
upsetting.
If
your
thing
went
out
with
overlapping
names
that
had
completely
different
signatures,
yeah.
B
It's
a
very
good
point
and
I
think
I
changed
this
name,
probably
close
to
five
or
ten
times
since
I've
designed
it
because
and
finding
a
name
that
doesn't
overlap
with
something,
because
we've
got
a
number
of
different
methods
in
the
compartment
API,
whether
its
import,
a
module
or
evaluate
I,
mean
there's
a
couple
of
different
different
things.
There
yeah.
A
A
A
E
A
The
other
thing
I'm
sorry,
besides
temporal
deadzone.
The
other
thing
is
the
live,
binding
aspect
that
the
exporter
of
the
of
the
module
name.
Space
object,
module
the
code
in
that
module
can
update
the
value
of
the
property,
whereas
the
code
holding
the
module
name.
Space
object
can
see
the
updates,
but
cannot
cause
updates
and
once
again,
that's
trivial
to
do
with
getter
setters
and
it's
more
with
getters
in
this
case,
and
it's
not
possible
to
do
with
non
exotic
data
properties.
C
There's
the
behavior
that
we
have
not
yet
defined
in
spec
that
we
may
choose
to
do
so.
Income
in
the
compartment,
shim
I've
been
fiddling
around
with
getting
inter
compartment,
pull
linkage
to
work
and,
at
the
moment,
mark
and
I
have
are
operating
on
a
premise
that
an
idea
that
there
would
be
a
new
function
on
the
compartment.
They
would
allow
you
to
get
the
module
name.
Space
object
for
it
has
been
loaded
or
executed
in
order
to
use
that
to
refer
to
a
module
in
that
compartment.
C
The
import
graph
from
one
compartment
to
another
and
execute
all
of
the
modules
together
to
link
connects
and
then
execute
all
of
the
modules
together,
and
in
order
to
do
that,
we
have
to
provide
a
module
database
object.
That
has
the
that
has
no
defined
interface
at
the
time
you
receive
it,
meaning
that
we
do
not.
We
do
not
know
what
getters
and
setters
it's
going
to
need.
C
A
B
B
Okay,
yet
so
the
module
objects
in
this
context
is,
it
is
actually
implemented
as
proxy
because
of
course
it's
a
it's
a
it's
a
it's.
An
object
returned
from
the
import
now
method
and
the
method
is
existing
in
the
host
Nijs
code
and
and
the
always
see
the
module
that's
being
imported
as
being
imported
into
the
virtual
machine
but
yeah.
So
it's
a
proxy
who's
whose
prophecies
reflect
the
global
variables
in
virtual
machine,
but
you
can
yeah
it
behaves
as
you
would
expect
a
local
object.
So
you
can.
A
B
D
B
B
I'm,
not
I'm
wondering
if
the
immutability
side
will
be
will
create.
Some
will
make
it
a
little
bit
impractical
to
use
in
some
scenarios,
and
also
there
were
a
few
things
that
were
emit
emitted.
That
might
be
quite
useful
for
I
can't
remember
exactly
the
past
four,
no
I'm
gonna
I
mean
I'm,
not
gonna,
speak
further
on
that
I
did
look
into
it
a
few
months
ago,
but
I
haven't
I
haven't
looked
at
it
recently.
My
my
expectation
is
that
it's
it
might
fit.
B
A
Okay,
okay,
well,
very
interesting,
okay,
another
question:
your
your
create
operation
on
your
interface,
microvia
yeah,
so
you're
using
a
you
know,
an
interface
language
here
and
you're.
Naming
something
static
create
is
that
it
need
to
map
to
a
JavaScript,
constructor
or
actually
to
map
to
a
static
method
named
create
it's.
B
A
static
method
then
creates
this.
The
document
here
is
sort
of
written.
As
you
know,
typescript,
it's
not
really.
You
can't
really
do
this
in
typescript.
It's
the
reason.
It's
not
a
constructors
just
because
there's
a
complimentary
restore
function,
so
you
can
create
and
snapshot
and
interest
all
and
both
of
them
both
of
them
create
a
virtual
machine,
but
the
one
is
restoring
it
from
a
snapshot.
Okay,.
A
B
A
Say
independent,
the
caller
of
create
is
getting
is,
is,
let's
say
in
micro
via
a
it
calls
create,
creating
a
micro
via
be,
but
the
micro
via
micro
VM,
object
that
represents
micro.
V&Amp;B
is
returned
to
the
code
in
micro
via
Mei.
Who
can
then
do
a
dot
global
this
so
clearly
the
object
graphs
can
be
come
freely
entangled
just
like
they
can
be
both
across
realms
and
across
compartments.
B
Yes,
it
would
be
a
in
this
example
or
in
these
examples
the
host
is
a
the
host
of
a
virtual
machine
is
no
js'
process
application
and
so
there's
the
host
and
the
virtual
machine.
I
think
that
if
you
had
two
virtual
machines
to
micro,
bian
virtual
machines
sharing
objects,
it
would
be
indistinguishable
yeah.
B
A
That
includes
things
like
the
body,
the
object
that
is
bound
to
the
name
object,
for
example,
the
global
name
array
that
would
be
as
if
I
compare
that,
if
code
in
micro
VM
a
use,
it
compares
array
triple
equal
micro,
B&B,
dot,
global
this
dot
array.
The
answer
would
be
that
they're
not
equal.
Maybe
they
are
yes,
okay,
okay,
so
this
this
is
really
analogous
to
the
realm
API
and
much
more
than
its
analogous
to
the
compartment
API.
B
B
B
It
takes
this
the
module
specifier
as
a
string
and
returns
a
gain
of
module
objects
and
again
the
requirements
here
for
the
module
objects
are
completely
flexible.
This
can
be
an
object
that
resides
in
the
host
or
it
can
be
an
object
that
resides
in
the
virtual
machine
or
another
or
another
virtual
machine.
It's
it's.
B
A
B
This
encapsulate
all
of
the
behavior
of
the
resolution,
there's
the
result
and
and
the
import
hook
of
the
compartment
API
and
that
is
taking
a
specifier
and
doing
whatever
it
required
what
it
was
needed
to
turn
into
a
module
object
and
and
another
critical
difference
between
the
sender
compartment
api's
hook.
Is
that
there's
no
referrer,
and
so
this
will
be
related
to
one
of
my
questions
that
I'm
going
to
ask
after
this,
but
the
module
hook
is
provided
I'm.
Sorry,
the
import
hook
is
provided
on
a
per
module
basis.
B
B
A
B
A
So
my
first,
the
thing
I'm
most
powerful
by
here
is
so
there's
you
know
somebody's
written
the
package
and
consists
of
a
bunch
of
modules
and
they're
importing
each
other
by
name
and
some
call
hold
on
connection
request
from
I'm
getting
a
bunch
of
zeros
to
connect
to
the
device.
Oh
I'm,
sorry,
this
is
not
a
zoom
thing.
This
is
a
completely
separate
thing
that
might
machine
was
asking
me
about
I,
don't
recognize
the
so
so
so
it
you
know
it's
somehow
in
any
of
our
systems.
A
We
end
up
trying
to
process
a
bunch
of
source
code
sitting
the
directory
into
a
set
of
linked
module
things
according
to
policy
decisions
about
who
can
see
what
and
renaming
and
all
that,
and
so
we
so
the
the
question
is:
how
does
one,
how
did
the
policy
decisions
that
have
been
somehow
expressed
somewhere
turn
into
import
hooks
that
are
provided
on
a
perl
module
source
basis?
How
does
this
import
hub?
That's
specific
to
this
module
get
into
the
module.
B
B
Sorry
I'm
just
looking
for
it
export
import
import
dependency,
so
this
is
this
is
example
an
example
or
written
in
Nijs
that
exercises
the
important
ow,
providing
a
important
import,
dependency
method
or
callback
and
I
don't
know
if
this
seeing
it
might
help,
explain
it,
but
this
is
taking
specifying
here.
It's
ignoring
the
specify
yeah.
The
policy
would
be
that
all
specifiers
resolved
to
the
same
module,
and
in
this
case
the
module
is
just
this
object
that
has
a
an
export
named.
B
X
logically
has
an
export
named
X,
because
the
module,
the
marginal
object,
has
a
property
named
X
with
a
value
of
10
and
the
imported
module,
and
then
therefore
import
import.
That
module
doesn't
know
what
the
specifier
is
here
and
get
access
to
that
to
that
value.
So
if
you
had
other
policies,
you'd
implement
them,
you
could
implement
them
within
this
callback.
We
can
say
it's
the
specifier.
Is
this
then
do
this?
It
encapsulates
the
module
map
and
capsule
AIT's.
B
The
resolver
encapsulate
s',
the
the
caching
memoization
behavior,
and
all
of
that,
all
of
that
is
within
this.
This
callback-
and
perhaps
the
other
answer
to
your
question-
comes
in
a
more
complete
example,
which
is
using
what
I've
called
the
node
style
in
corner.
This
is
a
function
and
a
built
in
as
a
utility
function
built
into
the
my
chromium
library,
but
is
separate
from
the
virtual
machine
itself
and
is
designed
for
hosts
running
in
low
jeaious
that
have
a
that
won't
want
to
have
modules
the
existing
file
system,
as
opposed
to
modules
that
exists.
B
Someone
else
like
a
database
or
whatever,
whatever
you
may
want,
and
the
way
it
works
is
that
you
call
the
node
style
importer.
You
give
it
some
options
that
tell
it
basically
the
policy
decisions.
This
is
this
is
not
in.
This
is
not
loading
up,
many
manifest
files
or
anything
like
that,
but
you
could
imagine
one
that
did
if
your
policies
were
captured
as
external
text
files
and
and
note
style
importer
here
just
takes
some
options
that
say
basically
what
what
is
the?
B
B
It
specifies
what
what
directory
to
look
in
it
specifies
a
bunch
of
modules
that
are
that
are
that
are
not
what's
the
words
that
are
absolute
in
a
sense
like
in
node,
you
can
say
import
if
they
import
from
FS
and
it
doesn't
matter
where,
where
the
importer
lives,
it
always
refers
to
the
same
imported
module
FS,
so
there's
no
sense
in
which
a
specifier
is
relative
to
the
importing
module.
So
that's
what
I've
called
core
modules
to
match
the
name
used
by
a
node
for
these
kinds
of
modules,
I
would.
C
D
C
A
full
specifier
is
like
a
canonical
specifier
in
the
context
of
a
compartment
and
which
is
to
say
that
it
and
correct
me
if
I'm
wrong
in
my
understanding
mark,
but
my
my
understanding
of
the
meaning
of
full
specifier
is
that
it
is
the
result
of
having
resolved
a
an
import
specifier
from
one
module
against
it's
against
the
refer
module,
specifier
and
the
semantics
of
that.
The
semantics
of
resolve
can
produce
either
absolute
or
relative
identifier
z--,
especially
for
nodes
semantics,
where
externally
linked
identifiers
are
always
absolute
and
internally
linked.
C
A
Now,
what
Michaels
doing
here
is
very
interesting,
which
is
by
just
providing
a
procedurally
defined
mapping
on
a
per
module
basis
and
then
having
constructed
the
module
objects
by
calls
to
you
know,
what's
what
is
currently
important
now,
essentially,
what
you're
loading
system
is
doing?
Your
notes,
style
and
Porter
system
is
doing?
Is
it
would
then
be
using
the
completely
the
API
that
Michael,
showing
once
per
module,
providing
the
right
functions
to
each
module
individually
to
do
to
make
all
of
the
decisions
about
about
when
this
module
uses
this
name?
What
does
it
mean?
A
A
I
think
that
the
same
issue
that
we
encounter
me
when
we
started
with
the
module
namespaces
as
the
things
designating
module
instances
that
you'll
encounter,
which
is
in
order
to
do
cyclic
linkage,
you
need
to
be
able
to
create
a
module
object
from
a
biscuit
from
your
case.
The
module
object
from
a
source
text
and
an
important
function
without
before
you
initialize
the
object,
so
these
are
employed.
So
so,
let's,
let's
go
back
to
your
your
type,
your
type
signatures
at
the
top
okay,
so
so
parallel
to
import.
A
Now
there
would
be
a
let's
call
it
module
now
for
for
no
good
reason,
but
module
now
has
exactly
the
same
signature,
but
the
difference
is
that
module
now
only
creates
the
MA
the
module
object
without
populating
it
and
without
without
doing
any
further
linkage.
It's
only
associating
the
source
text
with
the
hook
and
with
the
compartment.
A
But
it's
not
it's
not
itself
doing
any
further
linkage
and
it's
not
doing
any
initialization
and
that's
what
you
need
in
order
to
hook
these
thinner
to
wire
these
things
to
get
is
you
need
to
reify
them
before
they're
initialized,
so
that
you
can
have
them
to
wire
them
to
each
other?
And
then,
when
you've
got
a
complete
graph,
then
you
can
do
the
importing
or
evaluation
that
actually
does
the
initialization
and
the
transitive
linkage.
Does
that
make
sense,
yeah.
B
I
think
I
understand
what
you're
saying
I
think
that
that
problem
of
I
mean
this
is
basically
four
circular
dependencies
that
you
have
your
your
imports,
re-entrant
in
the
sense
that
you
can
import
the
same
module
whilst
being
imported,
and
it's
quite
it
was
quite
a
difficult
problem
to
find
us.
A
simple
solution
to
I
mean
complicated
solutions
that
are
easy
to
implement,
but
the
solution
that
I
went
for
in
my
Caribbean,
let's
see,
do
I
have
an
example
of
a
cyclic
import
here.
So
here.
B
So
the
source
modules
here
include,
so
they
have
for
each
module
name,
each
module
specifier.
They
have
a
source
text
and
and
in
a
callback
because
the
callbacks
provided
the
first
source,
and
here
we've
got
source
text
for
module,
a
that
imports,
module,
B
and
source
text
for
module,
B,
that
imports
module
a
and
each
one
and
it
has
a
corresponding
export
and
then
the
entry.
The
entry
here
is
just
to
call
the
import
hook,
which
is
just
a
function
that
takes
a
specifier
and
returns
the
module
objects.
B
I
call
it
on
the
absolute
specifier
for
the
entry
module,
which
is
probably
how
he
would
typically
do
it
anyway.
It's
just
that.
Normally
you
wouldn't
write
your
own
hope.
You
would
use
the
life
style
importer,
but
this
demonstrates
what
this
demonstrates
a
simple
case
of
those
cyclic
dependency,
our
circular
dependency
with,
without
having
all
the
complexity
of
the
note
style
importer,
and
so
this
imports
module
a
which
I
guess
the
the
evaluation
of
module
a
which
then
tries
to
import
module
B.
B
So
the
VM
is
going
to
hit
the
import
dependency
hook
for
module
a
which
is
going
to
find
the
final
module
B
in
this
table,
and
it's
going
to
then
start
executing
module.
B
module
B
is
then
also
importing
a
so
that's
the
the
cycle
and
a
has
not
completed
import
important
yet,
and
so,
let's
see
because
I
forgot
the
look
at
the
printout,
the
right
way
around
I
didn't
actually
executed.
This
example:
I
had
other
examples
of
cycles,
but
I
don't
know
if
I've
executed
this
one
module
a
yes.
B
A
Thank
you.
Thank
you.
Okay,
so
import
dependency
takes
in
a
specifier
and
returns
the
result
of
import
now
and
import
now,
of
course,
depends
will
cause
these
important
dependent.
You
know
cause
leads
the
the
hooks
to
get
called,
which
in
this
case
is
always
import
dependencies,
so
important
tendency
is
certainly
recursive,
which
is
not
surprising.
Now
you
start
by
calling
import
dependency
on
the
name
module
a
it
looks
up
the
module
source
object
in
the
modules
record
under
module,
a
which
is
the
thing
that
begins
on
with
begins
on
lines.
A
C
A
C
C
A
B
So
the
way
this
works,
assuming
there's
no
bugs
and
I've
thought
through
correcting
the
the
import
now
method,
which
will
be
evaluate
module
method.
If,
given
the
same,
it
is
specified
to
if
it's
given
the
same
module
source
will
return
exactly
the
same
module
objects.
So
I
think
this
is
what
Chris
is
saying
as
well.
It's
it's
memorizing
and
it's
memorizing
on
the
instance
of
the
module
sauce.
A
B
So
the
yeah,
the
process
of
importing,
creates
an
empty
objects
and
can
populate
at
the
moment
it's
cheating,
it
doesn't
populate
the
properties,
but
it
has
access
to
the
source
text.
So
it
could
populate
the
the
properties
of
that
module,
object
with
undefined
and
make
sure
it's
not
extensible,
and
all
of
that,
and
so.
D
B
B
D
B
C
C
B
The
bindings
are
live
here.
The
shortcut
have
taken
in
the
implementation
today
to
our
address
in
future
is
that
the
bindings
are
bi-directional,
so
you
can
actually
mutate
any
import
and
it
will
mutate
the
original
that's
that
can
be,
and
that
can
be
addressed
quite
easily.
I
think
down
the
line
and
I
can
do
a
test
case
for
it
just
to
make
sure
I
have
other
test
cases
for
cycle
dependencies.
They
probably
testing
for
the
wrong
thing.
Now
that
I
understand
the
temporal
dead
zone
scenario
better.
The.
B
Yeah,
but
they
can,
they
can
possibly
be
interchangeable
for
practical
purposes.
As
long
as
with
the
ndsm
behaviors
correct
the
behavior,
when
importing
a
host
defined
module,
that
is
commonjs,
it
probably
doesn't
need
to
match
some.
It
doesn't
even
need
to
match
either
specification
exactly
and
because
it's
an
ear,
it
would
be
a
new
cross
module
new
coding
style
it
that
hasn't
been
defined
previously
correct.
E
D
B
A
A
A
A
That's
fine
because
it
will,
when
you
come
around,
it
will
have
the
same
identity.
So
if
so,
it
registers
that
object
is
the
thing
to
return.
If
it's
asked
to
import
this
module
source
text
object,
it
does
it
does
that
registration
before
it
does
any
further
processing,
then
it
parses.
This
first
text
finds
the
name:
module.
A
B
calls
The
Associated
import
hook,
which
happens
to
be
important
tendency
in
this
case,
which
will
call
import
now
on
module
D,
which
does
the
same
thing
for
B
and
then
when
it
gets
to
the
step
where
it's
calling
import
now
with
the
source
object
for
module
a
MA,
the
import
now
will
first
check.
Do
I
already
have
a
module
object,
cache
for
this
import
object
or
the
source
object?
A
C
A
Module
method
for
creating
an
initialized
module
objects.
Can
we
just
do
all
the
wiring
during
the
import
recursion,
depending
on
the
caching
mechanism,
that
we
have
any
way
the
you
know
the
per
compartment
memorizing
mechanism?
By
having
it
do
the
memorizing
early?
We
can
still
do
a
during
import
and
not
have
to
do
any
other
wiring.
Is
that
possible
so.
C
This
way
and
I
think
yeah
and
it's
I
think
it's
worth
looking
into
the
as
for
whether
it
so
this,
of
course,
brings
up
the
question:
should
we
pivot
the
compartment?
Take
it
out
to
be
more
like
this,
and
part
of
that
is
part,
and
the
crux
of
that
is
like.
Could
we
avoid
having
to
expose
something
like
the
module
function,
I
think
with
the
compartment?
Api,
where
the
machinery
of
loading
and
linking
is
internals
of
the
compartment
and
across
compartments
I,
think
you
do
need
to
have
that
module
function.
C
My
intuition
about
whether
we
should
or
should
not
do.
That
is
that
we
should
not
because
there's
sufficient,
because
what
we've,
what
I
found
from
fiddling
around
with
the
compartment
shims
so
far,
is
that
the
machinery
that
is
encapsulated
by
the
compartment
API
is
sufficiently
general
that
you
can
express
the
semantics
of
both
node
style
resolution
and
web
style
resolution,
and
because
and
because
of
the
generalization
fits
inside
of
the
compartment
API
there's
some
utility
to
not
having
not
exposing
that
to
end-users
to
have
them.
C
E
D
C
B
A
E
A
For
from
just
some
absorbing
I
think
what
you're
doing
is
very
interesting,
I
think
this
is
a
very
worthy
experiment:
I
really
like
Chris's
description
of
the
relationship
between
the
two.
As
you
know,
one
is
the
inside
out
of
the
other,
so
I
think
it's
it's
it's
important
that
both
of
these
experiments
are
explored,
but
if
they're
both
going
to
proceed
to
be
implemented
and
deployed,
then
there's
the
issue
about
what
chaos
will
be
creating
by
their
coexistence.
A
B
B
What's
what's
the
word
and
look,
for
example,
at
MIT
that
many
to
many
relationship
between
full
specifiers
and
in
modular
instances,
if
you
have,
if
you
wanted
that
behavior,
you
can
implement
it
in
this
API,
but
not
the
compartment
API.
You
could
possibly
emulated
over
the
compartment
API
by
designing
a
more
complicated
serialization
mechanism
for
the
full
specifier.
So
you
could
have
like
a
instance,
a
colon
colon,
full
specifier,
and
then
you
pause
that
and
submit.
A
You
know
so
I
think
I
take
your
point.
In
earlier
phase
of
the
evolution
of
the
apartment
API,
we
were
exploring
having
full
expressivity
of
mapping
from
an
individual
mark.
The
important
aim
space
for
individual
modules
by
I
have
rather
than
that
was
when
we
were
talking
about
the
three
column
mapping.
A
As
we
recall,
there
were
mapping
from
the
refer
and
police
best,
the
specifier
to
the
module
object
young
to
to
the
the
thing,
the
thing
that
designates
what
it
is,
that's
being
imported
and
for
various
reasons
we
decided
to
give
up
that
generality
and
say
that
there's
a
resolved
that
only
goes
from
refer
and
specifier
to
full
specifier
and
then
there's
separately,
a
compartment
specific.
You
know
compartment
based
mapping
and
memo
that
goes
from
full
specifier
to
mark.
B
B
Yes,
I
think
the
same
I
think
the
compartment,
the
compartment
implementation,
a
compartment
class,
has
a
little
bit
more
functionality
baked
into
it.
Just
in
that
association
between
the
full
specifier
and
and
the
the
caching
mechanism,
the
memorization
table,
and
but
other
than
that,
I
think
the
separation
between
inside
and
outside
the
API
is
very
similar
between
that's
here.
This.
C
Feels
spiritually
very
similar
to
this,
but
to
the
proposal
that
we
have
in
mind
made
in
2010,
where
we
had
proposed
that
there
would
just
be
that
the
modules
that
the
only
primitive
that
the
engine
would
provide
to
user
space
for
modularity
would
be
a
module.
Constructor
function,
that's
very
similar
to
the
function
constructor,
but
it
would
take
a
module,
a
module
construction
and
it's
a
string
source
and
a
file
name
and
and
then
produce
the
factory
for
that
module
that
that,
but
that
you
would
that
you
would
pass
its
dependencies
in.
C
So
all
of
the
machinery
of
creating
linkage
was
on
the
outside
of
that
and-
and
there
was
quite
a
and
it
would
have
afforded
a
lot
of
flexibility
for
many
many
different
kinds
of
module
systems
all
on
the
same
tsin,
but
with
no
again.
Similarly,
with
no
I
mean
imposing
no
constraints
on
how
module
specifiers
were
that
on
the
semantics
of
multiple
specifiers
I
said,
then,
yes,
they
are
strings.
B
A
B
So
from
what
I
understand
of
this
I
think
the
question
might
be
easier
for
me
to
answer.
If
we
have
a
more
complete
documentation
of
the
compartment,
API
I've
been
digging
into
the
details
of
the
implementation,
to
try
and
understand
the
difference
between
module
and
import
now
and
import,
and
all
the
hooks
and
everything
and
by
the
implementation
is
not
not
the
clearest
way
for
me
to
to
understand
the
specified
behavior
and
is
it
possible
to
update
the
proposal
with
the
with
the
new
behavior.
C
E
Well,
we
definitely
don't
need
to
so
there's
an
interesting
precedent
here
and
the
service
worker
API
or
browsers
they
actually
requested.
The
top-level
await
be
implemented
in
such
a
way
that
if
you
do
not
use
it,
the
graph
must
evaluate
entirely
synchronously
and
they
went
so
far
as
to
exposing
a
field
on
it.
E
I
think
it's
just
called
sync
on
your
module
records
where,
if
you
don't
have
top-level
eight,
it's
identifiable
as
a
boolean
since
import
now
could
never
really
return
something
that
hasn't
been
initialized,
and
so
it
could
never
return
something
with
top
level
of
weight.
If
it
hasn't
been
initialized,
we
probably
don't
need
to
change
it.
The
implication
of
being
able
to
import
stuff
before
the
promise
resolves
is
still
a
timing
issue,
but
I
think
the
mandate
that
you
can
only
import
now
after
the
promise
handlers
have
been
fired
for
the
async
version
would
get
around.
E
Well,
currently,
in
the
spec,
it's
it's
possible
to
detect
it
at
the
engine
level
and
at
this
source
code
level
as
a
programmer.
There's
no
reflection
that
exposes
that
feel
to
anyone.
I
do
know
that
Wazza
modules
are
generally
async,
there's
some
gotchas
there,
but
they
cannot
be
loaded
synchronously
at
the
start
of
a
serviceworker
just
because
of
them
having
some
async
initialization
steps.
E
C
C
D
E
C
E
Only
usable
in
in
the
case
that
you're
trying
to
assert
that
sub
graphs
are
synchronous
mm-hm,
so
you
can
assert
that
a
sub
graph
is
guaranteed
not
to
interleave
any
micro
tasks
during
their
execution.
Since
your
only
question
was
about,
if
import
now
needs
to
return
a
promise,
it
explicitly
was
designed.
So
it
did
not
need
to
okay.
C
C
E
Yes,
with
one
added
caveat
that
it
cannot
return
something
before
the
async
handlers
fire
from
an
async.
So
if
you
queue
an
async
module
in
order
to
preserve
this
very
specific
thing
that
tc39
really
likes
the
right
of
first
access
and
the
inability
to
synchronously
inspect
promise
state,
we
need
to
allow
any
handlers
registered
to
drain
before
import
now
can
become
usable.
Oh
that's!
A
terrible,
confusing
thing
roughly
at
the
end
of
any
async
import
call,
so
you've
completely
finished,
evaluating.
C
Nailed
down
some
terms
that
you're
using
quickly
but
I'm,
not
entirely
certain
what
they
mean
but
I.
Let's
work
that
you're,
saying
async
import
call
I
to
resolve
the
ambiguity,
I'd
like
to
say:
let's
refer
to
the
import
function
of
the
import
method
of
a
compartment
as
as
simply
dynamic
import,
because
it'll
be
essentially
the
same.
Let's
record
to
import
now
as.
C
C
E
C
E
C
B
C
A
C
E
E
E
They
are
executed
in
first-in
first-out
order,
so
until
the
completion
of
your
dynamic
imports
module
graph,
so
the
end
of
the
source
text
it
has
not
been
placed
into
the
memo.
Cache
is
what
we
have
discussed
before
once
it
is
placed
into
the
memo
cache
that
is
shared
between
import
now
and
dynamic
import.
You
can
use
import
now
to
access
it,
even
though
it
was
created
asynchronously.
D
C
E
C
E
C
C
E
Cool,
so
the
key
here
is
just
that
when
you
place
something
into
the
cache
such
that
import
now
can
return,
it
mm-hmm
any
any
handler
that
was
attached
before
that
point.
So
if
you
use
dynamic
import
and
then
attach
a
dot,
then
on
it
must
finish.
Evaluation
before
import
now
can
return
that
value.
Oh,
that
is
strange.
A
A
That
is,
in
fact,
as
Bradley
was
saying
something:
that's
that's
a
invariant
that
that
tc39
has
has
preserved
and
bradwood
Bradley's
discussion
of
it
in
this
context
is
my
first
exposure
to
it
as
having,
as
you
know,
I
have
never
thought
about
what
that
means
in
this
context.
So
this
is
new
to
me
as
well.
Yeah.
E
C
Know
I'm,
yeah,
yeah,
yeah,
I,
know
right
and
I
think
that
the
term
you've
invented
for
it
is
quite
well
for
one
evocative
of
historic,
awful
historical
presidents,
but
also
also
perfectly
Act,
and
possibly
also
that
this
might
be
a
terrible
historical
president.
The
so
what
you're
suggesting
is
that
the
so
I'm
trying
to
think
about
how
you
would
implement
this,
and
it's
basically
I'm
think
that
the
way
that
you
implement
this
is
saying
is
by
having
a
lower
priority
queue
inside
of
the
promise.
C
For
for
adding
for
adding
adding
the
resolution
to
the
cache
such
that
any
any
any
dynamic
imports
between
when
and
any
dynamic
imports
between
before
your
import
now
call
get
to
be
added
before
that
entry
in
your
queue
and
engine
is
basically
basically
to
implement
to
implement
a
naive
implementation
of
compartment.
For
example,
the
one
that
I've
written
uh-huh
is
would
say
would
implement
import
as
a
first,
an
asynchronous
call
to
love
the
transitive
dependencies
and
dependencies
and
Link
them
followed
by
dot,
then
or
is
just
a
wait
upon
that
and
then
call
import
now.
C
What
you're
suggesting
is
that
that
is
not
sufficient,
that
we
need
to
also
I
think
this
is
how
yeah
the
way
I
would
implement.
What
you're
saying
is
a
requirement,
according
to
tc39,
would
be
to
say,
keep
a
record
of
every
promise.
I've
returned
from
import
for
a
particular
module
and
also
a
weight
on
promised
at
all
of
those
before
adding
it
to
the
cache
such
that
it
is
able
that
it
is
available
to
import
now
and
then
import
now.
Is
that
right
that.
E
Well,
after
you
finish
evaluating
your
dynamic
import,
you've
reached
the
end
of
your
module
graph.
That
is
the
point
in
which
we
want
to
make
it
available
to
import.
Now
we
could
queue
on
the
same
priority,
a
task
to
do
so.
That
would
not
allow
you
to
do.
You
await
dynamic
import
and
then
immediately
be
guaranteed
import
now,
if
we
did
it
that
way,
because
there
would
be
an
extra
tick,
so
that
would
require
another
await
perform.
E
B
If
you
got
so,
if
you
got,
if
you
call
dynamic
input
and
then
it
returns
a
promise
and
then
you
dot,
then
on
that
on
that
promise
and
then
within
the
then
callback
you
dot
the
end
on
the
promise
again.
So
not
the
results,
not
the
resolved
results,
but
the
the
original
promise
so
yeah,
it's
still
shadow
and
here
you're
appending
the
resolution
to
the
same
cues.
B
B
E
C
A
Alright
with
me
the
what
we
need,
what
we
practically
need,
the
realm
shims
for
allegoric
is
complete.
You
know
we
won't
need
top-level
await
at
all
until
there
are
significant
legacy,
libraries
that
use
it,
that
we
want
McLean
or
Nagor
to
be
able
to
use
those
libraries,
and
so
then,
as
far
as
the
shim
is
concerned,
we
can
ignore
top
level
away.
A
But
as
far
as
the
proposal
is
concerned,
in
order
to
advance
the
tc39,
we
have
to
understand
how
top
level
await
fits
with
the
overall
proposal
and
eventually,
since
the
shim
is
also
intended
to
be
a
shin
that
used
by
others
for
the
proposal
as
a
whole.
There
will
eventually
be
pressure
there,
but
not
for
a
long
time.
Yeah.
C
C
Yeah,
suffice
it
to
say
I,
don't
need
you
know,
I,
don't
even
know
how
one
would
observe
it's
it.
The
this
requirement
the
way
I
understand
it
is
capricious
in
the
sense
that
it
does
not.
It
does
not
seem
necessary
in
order
to
ensure
that
no
one
can
synchronously
observes
the
state
of
a
promise.
I,
don't
see
the
connection
to
that.
E
Okay,
so
it
is
more
than
that.
Actually,
there
are
two
parts:
one
is
not
being
able
to
synchronously
observe
the
promise.
The
other
is
the
ability
to
polyfill
or
mutate
things
in
a
guaranteed
first
in
first
out
manner.
In
order
to
achieve
both,
we
get
into
two
constraints:
for
the
inability
to
synchronously
inspect
a
promise.
We
have
to
use
this
memoization
table
that
is
only
populated
at
the
end
of
our
graph
evaluation.
Oh
I.
C
See
I
see,
I
see
the
the.
What
you
are
saying
is
not
that
this
is
necessary
in
order
to
preserve
this
invariant.
It's
that,
because
we
have
this
invariant,
we
must
go
through
extensive
and
go
to
extensive
additional
measures
in
order
to
ensure
a
property,
that's
necessary
for
something
else
correct,
and
what
is
that
something
else
you
mentioned
polyfills?
Yes,.
E
A
E
So
for
us
we
want
to
polyfill
something
on
temporal,
so
we
attempt
to
import
temporal
and
let's
say
we
are
the
very
first
source
text
to
import
temporal,
either
dynamically
or
matically.
If
we
are
the
first
to
import
tempura
and
we
can
attach
a
handler
to
that
dynamic
import
of
temporal,
that
guarantee
is.
We
are
in
a
position
that
we
can
replace
values
on
temporal
with
our
polyfill
such
that
any
course
text
later
we'll
see
our
replaced
values
rather
than
the
host
implementation.
C
That
my
position
on
this
is
and
I
suspect
that
mark
is
on
the
same.
It
is
on
the
same
place
with
this.
Is
that
in
an
internal
to
a
particular
compartments
in
module
graph,
it
is
too
late
to
ensure
any
invariants
about
the
ordering
of
shims,
and
the
vetted
shims
shims
in
general
should
be
executed
beforehand.
C
E
C
That
what
I
think
that
the
I
think
that
we
can
only
after
we
have
provided
an
alternative
approach
and
the
compartment
is
the
compartment
API
is
the
first
opportunity
in
order
to
create
an
alternative
approach.
Right
well
is,
if
you
want
to
have
a
module
graph
that
that
is
internally
executed.
After
all
of
the
shims
have
been
executed.
There
is
no
such
opportunity
if
you
are
already
inside
of
a
module
graphical,
a
particular
invisible
compartment,
yeah.
A
The
thing
about
creating
alternate
bindings
is
that
the
compartments
give
you
the
ability
for
a
to
create
a
an
emulated
environment
for
being
where
you
know,
so
it
controls
what
be
seized
rather
than
to
alter
your
environment
from
the
inside
before
other
things
start
running
should
be.
You
know,
because
of
the
way
JavaScript
works
and
no
shims
are
are,
you
know,
are
doing
the
customize,
my
my
own
world,
from
the
inside
before
I.
A
A
A
A
You
can
customize
the
other
primordial.
The
other
one
is
to
say
that
it's
not
it's
more
like
the
global
namespace,
if
this
other
import
namespace.
That
is
not
where
you
can,
where
it's
not
shared,
in
the
same
way
that
the
primordial
czar
shared
its
it's
sure
or
not.
According
to
the
policy
by
which
that
namespace
is
populated
and
just
like
the
compartment
is
a
means
for
creating
a
custom,
popular
custom,
bindings
of
global
names.
A
It's
also
a
mechanism
for
creating
a
custom
binding
with
import
namespaces,
and
therefore
you
can
replace
built-in
modules
or
any
other
modules,
with
replacements,
of
your
choosing
and
then
finally,
there's
the
issue
of
that.
When
you
do
this
customization,
do
you
do
it
by
modifying
the
exported
state
or
by
wrapping
the
module
you
know
or
by
replacing
the
modules
of
hold,
with
a
module
of
your
own
design,
which
might
be
a
wrapper
around
the
original
module.
E
E
A
A
A
It's
not
a
question
there's
an
ordering
which
then
callbacks
and
registered
it's
that
the
dependent,
then
callbacks
shouldn't
even
be
registered
until
the
one
that
needs
to
go
first
has
finished.
It
should
be
the
action
of
the
one
that
goes
first
that
enables
or
causes
the
other
ones
to
get
registered.
So.
E
I'm
gonna
use
a
little
bit
more
computer
science
II
terms
to
try
to
clarify
this
and
what
you're
saying
mark.
So
we
are
talking
about
barriers,
really,
yes,
and
if
we
want
to
apply
a
barrier
prior
to,
let's
call
it
application
code
versus
polyfill
code,
yes
or
if
you
want
to
apply
a
barrier
prior
to
these
first
access
rules
that
we've
talked
about
historically
yep
I,
don't
personally
have
a
stake
in
either
of
them.
I
think
really.
We
need
to
talk
to
Jordan
because
he
will
be
the
most
vocal
Jordan
harbin.
E
That
is
I,
think
at
least
for
Jordan.
The
viability
of
doing
things
everything
at
runtime
and
particularly
as
a
dependency,
which
is
how
polyfills
are
currently
loaded
in
the
ecosystem,
is
proving
more
and
more
difficult,
as
we
start
to
have
ES
modules,
particularly
top-level
await
in
value
in
Bali.
It's
sibling
guarantees
for
polyfills
and
Broadway's,
so
we
may
be
to
apply
this
barrier.
You're
talking
about
of
the
polyfill
code
must
do
whatever
it
does
and
then
a
barrier
is
applied
and
then
other
code
runs
yes.
E
D
E
E
C
What
I
think
that
what
so,
what
Polish
people
look
folks
writing
polyfills
want
is
essentially
for
there
to
exist
an
implicit
dependency
upon
the
polyfill
for
for
anything
imported
subsequently,
because
the
notion
of
a
polyfill
is
that
whatever's
being
polyfilled
need
not
know
about
the
polyfill,
otherwise,
it
defeats
the
purpose.
Mm-Hmm.
E
E
So
what
you
actually
have
to
do
for
this
is
in
particular
any
asynchronous
to
polyfill,
which
is
the
only
ones
we
care
about
which
uses
top-level
await
which
they
must
do
in
order
to
maintain
their
hidden
nature,
as
you
say,
must
go
and
actually
be
number
one.
The
first
module
imported
well,
it
must
be
imported
before
any
module
depending
upon
it
implicitly,
and
it
must
not
be
a
single
depth.
It
must
be
two
depth
because
siblings
execute
in
parallel
at
their
depth
level
whew.
E
C
Yep
sounds
good
and
I
can
hang
out
with
Brad
Bradley
if,
after
the
call,
if
in
order
to
fill
in
the
minutes
and
find
out
what
our
action
items
are
from
here,
my
suspicion
is
that
we
can
pivot
this
entire
discussion
to
being
a
presentation
of
an
opportunity
for
a
better
way
to
do
polyfills
than
what
you
have
to
do
today.
In
order
to
guarantee
these
the
implicitness
of
the
molecule
in
the
container.
E
E
E
D
B
E
E
C
C
C
C
D
D
D
E
D
E
C
C
E
So
we're
providing
this
idea
of
endowments,
let's
just
use
number
dot,
math
dot,
random,
sorry,
mm-hmm
as
an
example.
If
we
create
a
compartment
that
we
have
removed,
math
dot
random
with
an
attenuation
we
are,
there
is
confusion
on
what
happens
when
we
create
a
second
compartment
that
is
nested
within
the
censored
compartment.
Yes,
if
currently
historically,
you
would
get
access
to
math
dot
random.