►
From YouTube: SES-mtg: decouple staging dependency re builtin modules
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).
A
As
a
reminder,
the
incubator,
meaning
is
coming
up
soon,
they
send
they
invite
already
I
think
is
in
about
two
weeks
less
than
two
weeks.
Just
make
sure
that
you
know
how
to
invite
ask
us,
so
we
can
share
the
invite
and
it's
going
to
happen
right
before
the
next
committee
meeting
and
we're
trying
to
get
the
ball
rolling.
Is
things
go
well
in
the
meeting?
Then
we
already
had
a
in
I-10
into
the
agenda
for
next
meeting
for
Stage
three.
B
So
that's
stage
three
on
realms,
yes,
yeah
there's
also
been
a
meeting
that
another
pre
tc39
tc39
relevant
meeting,
which
was
meeting
of
the
group
interested
in
built-in
modules
and
there's
a
particular
political
issue
that
came
up
there,
that
it's
also
going
to
affect
the
incubator
meeting,
which
is
built
in
modules,
wants
to
go
to
stage
two
in
order
to
go
to
stage
two.
They
need
to
have
an
approach
to
the
remapping
of
them
of
the
import,
namespace
and
they're
currently
reluctant
to
have
that
depend
on
compartments,
they're
reluctant
for
a
number
of
reasons.
B
But
the
killer
reason
is
that
compartments
are
at
stage
one
and
they
don't
feel
like
they
can
go
to
stage
two
and
depend
on
compartments
wall
compartments
are
at
stage
one.
So
we
really
need
to
advance
compartments
to
stage
two,
but
that's
more
usefully
talked
about
if
Bradley
was
on
the
law.
Since
Bradley
is
the
author
of
the
proposal
that
would
go
to
stage
two,
but
I
do
expect
to
be
an
issue
at
the
incubator.
B
A
A
B
A
A
And
your
note
is
that
we
we
now
have
Leo
butter,
Leo,
Balter
working
so
forth.
Great
one
of
his
primary
goals
will
be
get
the
realms
to
Stage.
Four,
so
you'll
be
will
be
able
to
write
a
test
you'll
be
able
to
ride
whatever
needs
the
speck
on
the
tongue.
So
I
will
be
mayor.
I,
think
mayor
help
will
get
in
the
upcoming
things
that
we
need
to
do
for
it
great.
A
B
B
A
B
Calbert
made
a
suggestion
that
everybody
seemed
to
like
a
lot,
including
myself,
which
is
to
introduce
a
new
name
into
lexical
scope
like
import.
Now,
where
it
it's
argument,
is
a
specifier
string
and
the
outcome
of
calling
it
with
a
specifier
string
is
either
that
it
returns
a
module
name
space
object
so
that
the
caller
of
it
can.
You
know,
use
it
directly
for
pattern
matching
its
if
it
succeeds
or
as
Calvert
is
typing
head
or
it
throws
if
the
built
in
module
is
not
synchronously
available,
so
so
for
synchronous
access
from
scripts.
B
B
B
B
B
A
B
B
The
main
document
for
some
meaning
of
main
document
and
the
thing
that
it
has
to
be
able
to
import,
has
to
be
able
to
be
code
that
came
from
a
ship
where
the
code
where
the
shim
itself
is
only
loaded
asynchronously,
so
that
creates
a
tension
between
the
asynchronous
availability
of
shims
and
the
synchronous
availability
of
what
seems
to
be
built-in
modules
and
the
scheduling
of
the
execution
of
script
tags
in
a
browser.
So
those
are
the
three
things
that
have
to
be
brought
together
so.
A
B
B
Is
really
fascinating
and
that
way
you're
not
changing
what
is
in
any
objective
sense
the
import
namespace
of
the
code,
that's
running
it's
just
the
import
namespace
seemed
through
important
now,
but
the
it's
okay
and
then
import
now
would
would
still
would
have
the
the
the
the
modified
import
now
in
order
to
load
modules
that
could
themselves
just
use
import
declarations
to
load.
Other
shamed
modules
would
have
to
still
experience.
I.
Think,
there's
still
an
issue
here,
which
is
a
you
should
replace.
B
C
B
Shin
is
doing,
and
that's
too
painful
to
to
just
do
manually,
I'm,
to
ask
people
in
general
to
do
manual.
It's
the
whole
compartment
Shin
or
you
need
the
compartments
support
so
that
the
import
the
shimmed
import
now
can
use
the
compartment
to
set
up
the
namespace
seen
by
the
modules
that
it
load
yeah.
B
C
C
C
How
do
you
make
the
namespace
that
it
knows
about
available
to
import
declarations
of
any
module
you
load,
and
is
it
because
it's
sufficient
to
have
an
it's
sufficient
to
the
scope
of
a
particular
script
to
replace
import
now
on
the
global,
but
it
is
not
sufficient
to
then
be
able
to
say
dynamic,
import,
another
module
and
for
the
module,
your
or
dynamically
importing
be
able
to
act.
That's
the
names
of
the
namespace
that
you've
created.
C
I
think
that
the
set
import
function
is
doomed
for
a
number
of
other
reasons,
but
but
if
you
were
to
even
just
reduce
it
to
its
the,
even
if
you
were
to
introduce
it
to
the
simplest
form,
which
is
just
a
function
that
says
hey
from
within
this
compartment,
I
introduced
this
built-in
module.
With
this
name.
A
B
Me
focus
in
on
what
particular
thing
that
cupboard
said
that
I
think
is
the
the
easiest
way
to
highlight
the
problem
that
this
doesn't
solve,
which
is
scripts
already,
can
use
dynamic,
import
dynamic
import
is
not
a
lexical
variable.
It's
a
it's
a
its
syntax.
It's
a
special
form
right
now.
It
goes
directly
to
the
host
and
the
what
we're
doing
with
compartments
at
the
JavaScript
level,
but
but
till
now
never
thought
about
it.
The
HTML
level
is
by
creating
a
new
compartment.
B
You
you
in
the
new
compartment,
has
a
new
import
hook
as
well
as
new
import
now
hook,
and
that
way
controlling
code
can
can
can
provide
the
namespace
that
the
controlled
code,
the
code
inside
the
compartment,
sees
when
it
does
a
dynamic
import
expression.
If
you
do
just
the
sequential
execution
of
script
tags
with
a
replacement
of
import
now,
those
same
scripts
can
still
use
dynamic
import,
but
the
earlier
shimming
code
has
no
way
to
change
what
namespace
that
dynamic
import.
B
States
right,
you
have
to
we'd,
have
to
replace
both
the
namespace
seen
through
import
now
and
the
namespace
seen
by
dynamic
import
and
the
namespace
seen
by
by
import
declarations
and
the
module
so
loaded
and
I,
don't
think
it's
viable
to
do
that
in
the
context
of
the
code.
That's
already
running
yeah.
D
A
Because
let
me
try
to
see
again
explain
why
I'm
confused
okay,
so
there
are
two
things
that
you
most
likely
want
to
do
on
a
standard
library
that
is
provide,
whether
that's
a
building
or
is
a
global,
accessible
API.
There
are
two
things
that
you
might
want
to
do
you
want
to
replace
it
entirely
or
pieces
of
it
or
you
want
to
introduce
something
that
is
not
there
so
yeah.
If
you
are
doing
a
built
in
module
which
offer
you
API
to
do
some
operations,
you
most
likely
will
have
the
same
kind
of
thing.
A
Sometimes
you
just
want
to
add
one
thing
into
one
of
the
prototypes
that
are
accessible.
We
are
one
of
these
buildings
and
you
should
be
able
to
do
so
by
just
doing
import
now.
I'm
changing
the
pieces
of
it
by
adding
new
things
were
changing
things
that
exist
in
the
proto
for
the
types
of
those
things
that
you
accessed
via
the
input.
Now
the
there
are
limitations
there,
of
course,
because
you're
getting
a
namespace
out
your
back,
the
name
is
space
up.
There
is
no
mutable.
You
cannot
add
a
new
thing
that
this
library
export.
A
That
has
never
been
seen
by
by
this
this
window,
this
realm
running
in
a
browser,
but
in
order
for
you
to
achieve
that,
you
have
to
have
the
ability
to
either
create
synthetic
namespaces
name
is
base
updates
or
having
a
way
to
produce
something
that
looks
like
a
namespace
out
that
can
be
seen
or
you
by
some
sums
are
right
by
whoever
calls
input
now.
I'll
say
that,
probably
that
second
option
is
not
really
an
option.
A
You
really
need
to
have
a
name
in
spades
up
to
that,
you
can't
hand
it
over
to
someone,
and
the
component.
Api
has
some
of
that.
As
far
as
I
can
tell
the
ability
for
you
to
produce
in
naming
space
object
that
you
fully
control
somehow
using
some
API
stew
in
the
past.
We
call
this
the.
What
was
the
name
that
we
use.
They
take
harmonies
a
they
name
put
it
the.
A
Reflective
module
API
or
something
like
that
or
remember,
but
the
ability
for
you
to
create
a
namespace
object
and
if
you
do
import
now,
you're
going
to
get
one
of
these
things
that
I
that
are
implementing
the
new
API.
So
up
to
that
point,
because
this
is
observable
only
at
the
script
level,
everything
seems
to
be
fine.
What
I
understand
that
you're
saying
is
that?
Because
you
have
autumn
means
to
access
the
same
namespace
object,
there
might
be
some
inconsistencies
that
you
will
be
able
to
to
observe
yeah.
B
Let
me
just
focus
focus
more
concretely
on
the
same
thing:
I
was
trying
to
focus
on
because
I
think
it's
impossible.
In
this
scenario,
let's
say
that
the
browser
already
has
a
built-in
named
temporal,
but
it's
not
right
in
some
way,
maybe
maybe
there's
a
new
version
of
temporal
and
you
can't
get
make
it
right
by
using
the
same
instance
and
just
modifying
the
objects.
B
What
you,
what
the
shim
wants
to
do
is
load
a
new
module
to
occupy
the
name
temporal
where
the
new
module
is
implemented
in
terms
of
the
old
modules,
and
this
is
our
attenuation
scenario,
but
this
is
applied
to
shimming,
so
the
the
shim
is
able
to
import
the
old
built-in
Jayne
genuinely
built-in
temporal,
and
it
makes
use
of
it
in
order
to
export
a
new
thing
that
other
code
executing
after
the
shim
or
in
the
environment,
created
by
the
shim
it.
When
it's.
When
when
that
new
code
says
import
temporal,
it
should
see
this.
B
It
should
see
the
temporal
module
created
by
the
shin
and
therefore
it
needs
to
be
the
thing
that
is
seen
through
the
import
namespace,
whether
the
important
aim
space
is
accessed
by
the
import
now
or
accessed
by
a
dynamic
import
expression
or
accessed
by
an
import
declaration
in
any
of
the
modules
that
are
loaded
and
the
so
now.
The
question
is:
how
does
the
shim
change,
what
the
name
temporal
maps
to.
B
No,
that's!
That's
that's.
My
point
is
I'm
talking
about
if
temporal
were
made
into
a
built-in
module
and
then
somebody
wrote
a
shim
okay,
Laura,
okay,
she's
Kim
of
temporal
okay.
How
do
you
write
a
shim
of
temporal
where
the
shin
is
is
cannot
achieve
its
goals
by
modifying
the
objects
of
the
existing
temporal
built-in
instance,
but
rather
needs
to
install
a
new
module
such
that
all
of
the
things
affected
by
the
Shin?
B
A
Let
me
see
you
have
to
be
a
little
bit
crafty,
but
assuming
the
absorbing
difference
between
the
import,
our
namespace
and
the
name
is
space
that
you
can
get
by
doing
a
regular
import
or
a
import
statement.
It's
not
an
issue.
I'll
say
that
you
have
to
be
crafty
to
produce
a
nameÃs
phase
when
you
do
in
for
now.
B
I'm
saying
it's
a
requirement
that
any
way
of
importing
for
the
code,
that's
in
the
environment,
that
that
the
shim
was
trying
to
set
up
whether
it
uses
an
import
declaration,
a
dynamic
import
expression
or
an
import.
Now,
always
it
importing
in
the
code
that
that
the
that's
executing
in
the
environment
that
the
shim
was
trying
to
produce.
You
know
the
shim
is
trying
to
create
an
environment
that
emulates
the
future
version
of
import
now.
B
A
A
In
other
words,
I,
don't
see,
the
name
is
space
object,
as
the
built-in
capability
that
you
are
accessing,
I
see
it
as
a
mean
to
access
that
capability,
but
not
a
capability
itself.
So,
of
course,
if
we
call
it
import
now
that
looks
a
lot
like
import
and
therefore,
probably
you
expect
a
namespace
object,
but
if
you
want
to
access
the
capabilities
in
a
form
that
is
not
necessarily
a
namespace
object,
you
just
want
the
capabilities.
You
don't
care.
If
it
is
a
name
is
Baisakhi
or
not,
then
you
eliminate
this
problem
entirely
and
so.
B
So
so
I
don't
understand
that,
let's,
let's
say
that
you
relaxed
it
that
way
where
it
can
be
a
different
name,
space
object,
but
it
should
still
be
an
a
an
instantiation
of
the
code
installed
by
the
sin
by
the
Shin.
The
original,
the
original
built
in
temporal
should
that
the
behavior
of
that
code
to
access
to
that
behavior
should
no
longer
be
possible
in
the
emulated
environment.
Could.
E
E
E
But
if
you
use
the
namespace
object,
you
simplify
how
you
write
your
specs
in
2015
by
saying
that
has
to
be
initialized
to
imply
that
the
scope
of
that
getter
has
been
initialized,
and
so
so
the
cyclic
problem
was
fact
out
that
way.
I
don't
think
we
need
to
give
too
much
attention
to
to
the
name.
Space
object
way
to
suspect,
but
rather
to
what
it's
guaranteed
and
if
you
access
a
getter
before
its
namespace
is,
is
set
to
initialize
that
behavior
I.
B
So
the
thing
I
want
to
focus
on
is:
let's:
let's
drop
the
namespace
object
for
a
moment.
We
have
to
come
back
to
it,
let's
drop
it
for
the
moment
and
just
talk
about
what
behavior,
what
code
behavior
you
see
when
you
import
temporal
and
our
requirement
is
that
all
code,
including
in
script
within
script,
tags
within
HTML,
all
code,
that's
executing
in
the
environment
that
the
shim
was
supposed
to
create
that
no
matter
how
it
imports
the
specifier
temporal
and
no
matter
what
namespace
object.
B
A
B
A
A
B
A
A
When
you
import,
when
you
do
that,
you're
going
to
load,
that
is
script
when
someone
imported
statically
or
dynamically,
it
will
go
and
fetch
that
thing
and
when
you
fetch
that
thing
is
basically
a
sure
it's
a
thing
that
what
it
does
is
just
simply
exporting
the
things
that
it's
getting
out
of
the
current
global
it
gets.
It
gets
the
things
that
were
installed
somehow
by
the
by
by
the
polyfill
that
is
giving
access
to
the
tempura
bits
that
you
need
to
export
and
it
just
export
them.
So.
B
The
problem-
the
import
map
right
now
is
only
declarative
in
the
HTML
and
therefore
exists
before
any
code
starts
running.
If
you,
if
the
shim
accesses
the
is
able
to
determine
the
import
map
by
API,
is
it
the
shim
is?
Is
JavaScript
code?
That's
already
running,
does
does.
Are
you
so?
What
they're
proposing
what
I'm
I'm
saying
I
don't
want
to
see
is
that
they're
bit
that
there's
a
import
map
mutation,
primitive
so
that
you
modify
the
import
map
that
you're
running
in,
even
though
you're
already
running.
Is
that
what
you're
it.
A
D
Offer
another
perspective
on
this,
which
is
at
the
existing
solution
for
shims,
is
that
they
they
can
mutate
the
environment
to
replace
name
bindings.
For
example,
if
you
had
a
shim
for
the
array
to
pick
something
simple
and
the
shim
can
replace
the
global
array
with
its
own,
which
is
essentially
changing
the
the
binding
from
you
know,
when
code
tries
to
get
something
called
array,
it
will
then
get
the
the
shimmed
array.
So
that's
a
mutation
of
essentially
a
specifier
to
object,
binding,
which
is
just
a
global
with
global
property
or
global
global
variable.
D
But
the
analogous
behavior
in
in
the
built-in
modules
way
of
doing
things
would
be
a
way
of
mutating
that
binding.
So
if
array
was
a
built
in
module,
a
temporal
was
a
built
in
module
that
you'd
have
access
to
mutate
it,
and
then
the
mutation
would
have
effect
after
the
mutation,
but
not
before
so
imports
after
that,
so
I
see
them
as
equivalent
in
some
way
equivalent
solutions.
So
if
there
are
problems
with
mutating
the
global
map
dynamically,
while
the
code
is
running
then
do
those
problems
also
exhibit
themselves
with
the
current
solution.
D
And
that
would
be
my
question
and
if
they
do
then
maybe
the
we
can
point
to
examples
of
that,
as
reasons
not
to
mutate.
The
global
map,
the
import
map
and-
and
if
there
aren't
any
issues
with
that,
then
maybe
that's
just
an
alternative,
an
alternative
way
of
solving
the
problem
for
people
who
haven't
yet
constructed
a
compartment
that
they
want
the
global
card
to
be
existing
in
a
mutable
environment
like.
C
What
you're
saying
Michael,
because
I
think
that
it
highlights
how
far
we've
gotten
into
the
weeds
into
the
into
the
crux
of
this
conversation,
I
think
that
all
of
us
could
get
to
a
point
where
we're
agreeing
and
I
accept
intuitively
that
it
is
possible
to
implement
built
shimming
for
built-in
modules,
either
using
the
compartment
API
or
using
a
self
mutated
yeah.
That's
more
like
the
traditional
polyfill
idea.
I
think
that
they're
both
possible.
C
But
what
the
sticking
point
is
I
think
is
when
we
get
all
the
way
up
to
assess
all
of
the
mitigations
that
we
needed
to
make
the
polyfill
style
of
shimming
the
environment
with
use
and
just
mutating
the
global
them
transitively
mutable
global
scope.
Neat
we
need,
we
would
need
a
similar
recourse
for
the
module
map.
Oh.
D
C
E
Sorry,
you
saw
so
I'm
just
gonna.
Take
it
back
to
you
know
when
I
thought
about
why
the
namespace
object
was
very
important
in
2015
you're
making
loose
bindings
in
an
importer
module
scope.
Those
are
bound
variables
that
relate
to
two
variables
that
exist
in
another
scope.
So
namespace
objects
have
50%
what
your
binding
against
when
you're
using
it
in
the
important
module
and
the
other
50%,
is
what
your
binding
from
and
if
you
can
get
rid
of
the
requirement
of
either
50%.
E
If
you're
not
binding
from
a
scope
and
or
binding
into
a
scope,
then
then
that
restriction
is
much
looser
and
technically
you
can
mutate,
because
it's
like
an
exports
object,
you
know,
and
in
commonjs
it
is
an
object
and
objects.
If
you
want
to
take
something
and
keep
it,
you
could
just
D
structure
them,
and
if
that
value
changes,
that's
your
mistake.
E
You
don't
use
commonjs
exports
by
by
restructuring
them
unless
you're
certain
that
this
is
how
you
want
to
use
them,
and
the
same
would
apply
to
an
import
the
namespace
object,
but
it
wouldn't
apply
to
an
import
to
declaration.
Hence
the
need
to
to
make
sure
you
don't
dynamically
rebind
what
it
links
against
when
it
statically
imported
that
that
kind
of
changes
you
know,
breaks
the
semantics
of
why
2015
modules
were
written
that
way,
so
yeah
I'm.
A
E
C
I
think
that
that
I
think
that
we
could
easily
satisfy
that
requirement.
Whatever
names
face
it
you
register
in
the
module
map,
is
akin
to
the
internal
scope
of
that
module
and
if
you
were
to
import,
if
you
were
to
dynamically
import
that
module,
you
wouldn't
get
the
exact
same
object,
you
would
get
a
view
into
that
object.
That
would
preserve
the
invariance
of
that
an
export
namespace
provides,
but
let's
get
back
to
let's
get
back
to
mutation
of
the
module
map
from
within
or
without
yeah.
B
There
so
I
want
to
come
back
to
it
and
see
if
we
can
iron
out
some
of
the
difficulties
with
it.
We
make
it
a
a
a
full
proposal
we
can
go
with,
but
I
want
to
acknowledge
that
Michael
and
kriti,
and
the
other
champions
of
built-in
modules
I
think
are
all
on
the
same
page
with
doing
it
from
the
inside
and.
A
B
B
B
All
of
this
is
that
all
of
the
module
instance
linking
decisions
are
already
made
before
any
of
the
code
in
the
module
graph
starts
running
and
that
so
that
set
of
linking
decisions
together
is
effectively
atomic
and
all
of
the
and
all
the
code
in
the
linked
module
graph
only
happens
after
that
atomic
step.
So
I
think
we
could
take
the
consistent
position
that
all
of
the
you
know
that
that
atomic
linking
step
happens
in
the
import
environment
at
that
time.
B
B
Let's,
let's
just
be
careful
about
the
analogy,
would
be
array
the
array
constructor,
not
array
prototype
because
not
yeah.
The
array
prototype
is
undeniable
yeah.
The
r8
constructor
can
be
replaced
yeah.
So
yes,
that
that
would
follow
from
the
analogy
anybody
that
grabs
the
array
constructor
before
it's
replaced
still
has
the
array
constructor
yep.
A
So
a
couple
of
nodes,
sigh
nodes,
so
most
people
who
will
be
using
import
now
or
the
equivalent
of
it
just
like
people
who
use
a
import
dynamic
import
today.
They
would
just
simply
destruct
that
thing,
so
they
never
really
halt
on
to
the
namespace
after
they
just
simply
destructed
the
most
people,
especially
in
this
case
that
would
be
synced
or
not
a
sink
and.
A
A
C
Let
me
I
think
that
I
think
that
mark
is
at
least
at
the
Marcus
stated
that
he's
at
least
at
the
point,
where
he's
conceding
that
it
is
possible
and
coherent
to
have
a
notion
of
how
to
do
built-in
shims.
That
is
coherent
with
the
the
within
itself
and
with
the
idea
of
how
to
do
shimming
on
objects
in
global
scope.
Yeah.
B
C
That,
yes,
I,
think
but
I
think
that
we
want
to
not
simply
given
that
far
I
think
what
we
want
to
do
is
to
also
make
sure
that,
assuming
that
we
were
to
adopt
this
notion
of
how
to
do
shims
within
from
within
a
compartment,
what
else
do
we
need
in
order
to
be
able
to
do
assess
properly
in
that
world?
And
we've
already,
we've
already
discussed
that
there
needs
to
be
some
mechanism
for
locking
down
yeah
module
import
map.
B
B
That's
correct.
The
other
thing
is
that
we,
the
lockdown
issue.
We
need
to
not
only
walk
down
mutation
of
the
import
namespace.
We
also
need
to
do
petrify
the
state
of
all
the
built
in
module
instances
so
that
none
of
the
doulton
module
in
so
in
exactly
the
same
way
that
we
petrify
all
of
the
built-ins,
the
shim
petrifies,
the
built-ins
by
manually
walking
the
graph,
because
it's
a
shame,
but
the
proposal
just
says:
lockdown
walks
all
of
them
down.
B
B
You
know
the
the
proposals
about
what
things
get
to
be
built
in
modules,
that
we
extend
the
philosophy
that
we've
already
the
discipline
that
we
have
already
applied
to
the
primordial,
which
is
that
computational
api's
are
purely
computational,
that
they
have
no
hidden
state.
They
have
no
Iowa
and
then
powerful
things
that
bring
in
kidness.
B
That
sort
of
necessarily
by
their
semantics,
bring
in
state
or
I
owe
a
going
like,
for
example,
of
the
we
craft
constructor
that
those
are
cleanly
separated
and
so
that
they
can
be
shimmed
or
replaced
or
denied
or
Co
censored.
That
separately,
while
leaving
the
country
computational
api's
same
object,
identity,
so
there's
no
identity,
discontinuity
so
applied
to
built-in
modules.
What
that
says
is
that
we
would
have
two
categories
of
module,
but
that
default
built-in
module
would
be
purified.
D
C
Concede
that
they
do
not
need
to
couple
to
the
compartment
API
and
propose
I,
don't
think
we
need
to
propose
much
and
certainly
not
in
the
context
of
the
compartment
or
assess
proposing.
I
would
like
to
propose
that
they
simplify
the
mechanism
they're
proposing
for
introducing
names
to
the
module
map.
B
B
C
Okay,
let's
see,
let's
see,
let's
see,
do
we
wish
to
in
our
last
45
minutes,
tackle
the
global
contour
issue
again
and
maybe
get
that
closer
to
a
resolution
or
one
of
these
other
topics.
I
do
not
have
the
preparation
for
the
topic:
I
proposed
for
module
and
load
method
methods
and
Bradley's
not
present.
C
B
D
E
F
About
that,
as
I
was
saying
at
the
very
beginning,
I
went
through
the
list
of
proposals
that
are
outstanding
stage,
three
two
and
one
and
zero,
and
it
looks
like
there's
about
20
of
them.
So
even
if
we
wanted
to
review
them
five
minutes
per
subject,
there
wouldn't
be
enough
time
in
a
single
meeting
to
do
that.
So
we
may
have
to
plot
a
couple
meetings,
just
two
or
maybe
even
three
meetings
to
go
through
them
all
and
just
take
a
quick
glance
at
okay.
B
B
C
Yeah,
that's
that
sounds
like
an
enormous
quantity
of
work,
but
totally
valuable
I
mean
I.
Have
I
have
a
similar
piece
of
work
on
my
docket
I
need
to
review
all
of
the
issues.
Incest,
so
I
know,
what's
going
on
I'm,
not
yet
oriented
I
think
doesn't
need
to
comb
the
backlog,
so
Caretti
yep.
Okay.
What
do
you
remember
of
the
the
difficulties
that
the
global
contour
had
last
time
it
was
proposed
that
we
might
have
to
overcome
if
we
in,
if
we
entrained
it
into
the
compartment
API.
A
A
A
Don't
remember
if
the
yeah
I
think
if
you
open
the
issue,
there
might
be
something
there.
Maybe
I
copy
something
in
the
issue.
I,
don't
remember.
Yeah.
C
A
A
D
A
Another
example
of
it
in
the
rapport
you
you
you,
even
even
today,
in
dev
tools
up
to
very
recently
the
dev
tool,
you
create
a
cons
and
then
you
try
to
recreate
it.
It
just
problematic
and
recently
browsers,
I,
think
Ramdev
to
allow
you
to
really
find
a
cons
now
Apple
in
a
console.
So
there
are
some
things
that
have
changed
since
the
last
time
that
we
discussed
these.
There
might
be
some
new,
some
new
things
that
we
have
to
look
into.
How
we
do
it
in
the
report
in
the
wrapper
was
a
good
example.
A
C
A
C
A
C
Yeah,
which
means
that
it,
which
means
that
you're
introducing
a
property
that
is
non
writable,
but
if,
if
you
were
to
have
two
subsequent
evals,
so
the
effect
on
the
global
contour,
there's
no
equivalent
of
a
delete.
In
that
case,
like
right,
the
property,
the
proper
there
continues
to
be
a
a
a
non
configurable
property
that
continues
to
be
non
writable.
A
The
cons
is
also
about
the
left
mm-hmm,
because,
if
I,
if
I
execute
some
code,
that
does
a
let
that
add
something
to
the
contour
and
then
I
have
a
function
as
part
of
that
that
eventually
use
that
binding.
If
you
delete
it
from
the
contour
and
you
execute
a
function,
it
will
throw
an
error.
Yes,
we.
B
It's
tied
to
get
it's
tightly,
configurability
in
in
one
direction.
It's
important
to
always
remember
this,
which
is
if
the
proxy
claims
that
it's
not
configurable,
then
it
must
not
allow
it
to
be
deleted,
but
it's
perfectly
fine
and
allowed
by
the
object
and
variance
and
allowed
by
the
proxy
mechanism
for
an
object
to
claim
that
a
property
is
configurable
but
refused
to
configure
it
and
as
well
as
refuse
to
delete
it.
It's
it's.
The
things
that
are
binding
are
only
the
promises.
Stability.
There
is
no
binding
promise
of
instability,
so.
A
A
C
Yes,
yes,
yes,
yes,
yeah.
The
reason
why
I'm
proposing
the
reason
why
I'm
proposing
that
this
this
could
be
modeled
with
the
proxy
is
because
the
special
behavior
of
the
global
contour
is
that
any
that
every
property
introduced
must
also
be
non
configurable,
so
that
it
cannot
so
that,
in
order
to
preclude
the
possibility
of
deletion
because
creating
a
hole
in
the
scope
chain
is.
B
If
you
does,
if
the
the
property
was
non
configurable
Mon
writable,
then
we
would
not
be
able
to
change
its
value
because
that
would
violate
the
object.
Invariants.
However,
with
exotic
behavior,
we
can
have
the
property
say
that
it
is
non
writable
but
configurable,
but
only
accept
whatever
special
case
of
reconfiguration.
We
were
interested
in
such
as
in
this
case
very
specifically,
the
it
could
reject
all
reconfiguration,
except
for
changing
the
value,
so
its
effect
effectively
writable.
But
it's
not
writable
by
their
by
assignment
it's
only
writable
by
defining
property.
So.
E
E
B
E
B
You're
correct
but
there's
there's
there's
a
some
qualifications
there,
a
top-level
var
in
strict
code,
evaluated
as
eval
code
yeah
does
not
create
yeah
anything
external.
But
if
it's
evaluated
as
global
code
or
if
it's
sloppy
in
those
cases,
a
var
and
function
just
create
a
binding
on
the
global
object.
Yes,.
E
So
so
the
idea
that
the
contour
would
have
a
delete
operation
where,
where
it
is
scoped
on
to
your
scope,
I
think
I
think
you
get
to
modify
the
contour
in
a
privileged
sense
and
and
the
consumer
would
basically
just
see
that
contour
variable
or
contour
contributions
or
endowments
as
as
bindings
in
a
sense.
If
you
want
to
modify
a
global
contour
value,
you
could
not
think
of
it
as
an
assignable
property,
but
but
rather
as
a
function
that
you,
you
know,
Java
style,
setters.
E
E
C
You're,
certainly
heading
where
my
mind
is
thinking,
and
that
is
mark
proposed
a
caveat.
It
was
like
an
important
caveat
if
we
were
if
we
needed
to
reify
the
global
contour
as
an
object
and
that's
a
big.
If,
for
the
purposes
of
the
contour
for
the
purposes
of
the
compartment
API,
it
may
not
be
necessary
for
us
to
reify
it
at
all.
We
just
need
an
ability
to
initialize
it
with
a
particular
set
of
fields,
and
that
might
be
our
way
around.
C
And
I'm
not
sure
that
whether
those
exist
anymore
do
something.
So,
let's
just
review
to
make
sure
oh
no,
no,
no,
we
do,
one
of
them
was
well.
One
of
them
is
relaxed.
Bradley.
In
the
discussion
we
were
just
finishing
up.
We
have
reached
a
concession
that
the
built
in
module
proposal
does
not
need
to
be
coupled
to
compartments
it
just
need.
We
just
need
to
be
sure
that
there
is
a
lockdown
mechanism
for
the
module
map,
if
it's
being
edited
from
within
the
so
then
the
reason
why
that's
important?
That's
why?
C
Accelerating
the
compartments
API
so
that
we
could
get
to
stage
two
before
built-ins
did,
but
we
no
longer
have
that
constraint.
I
do
think
that
we
could
advance
to
stage
two
concurrently
and
it
perhaps
worth
discussing
what
we
need
to
do
to
get
to
the
point
where
we
can
propose
that.
That's
largely
something
we
have
to
ask
you
since
it's
it
could.
It
is
involves
your
time.
C
D
C
No
no
I
I
had
I
wanted
to
propose
module
and
load
methods
for
compartment,
but
I
still
have
homework.
To
do.
I
need
to
I
need
to
create
I
need
to
create
a
demonstration
of
why
those
methods
would
be
usable,
useful
for
the
purposes
of
creating
a
bundler
and
so
yeah,
again,
okay,
cool.
We
can
return
to
the
global
contour
discussion.
Okay,
great!
C
B
C
If,
if,
instead
of
introducing
problem
so
for
the
purposes
of
the
are
motivating
use
cases
for
the
global
out
for
having
a
way
to
introduce
properties
of
the
global
contour,
we
would
only
need
to
be
able
to
thread
them
through
the
compartment
constructor
and
then
have
them
surface.
On
the
global
contour
inside
inside
the
compartment.
C
It
I
don't
think
that
we
need
to
create
an
object
with
that
name
and
because
of
that
I.
Don't
think
that
we
actually
need
to
consider
too
deeply
the
configurability
or
delete
ability
of
properties
on
that
object.
It
could
become.
The
implementation
of
the
contour
could
be
entirely
internal
to
the
compartment
and.
A
D
B
A
D
C
E
A
A
D
A
B
Yeah,
what
my
I
think,
you
know
I
think
eventually,
pressures
might
push
us
towards
being
able
to
emulate
it,
but
yeah.
My
position
right
now
is
the
same
as
Bradley's.
Is
that
the
whole
window
versus
window
proxy
thing
is
not
something
I'm
interested
in
spending
in
the
effort
trying
to
emulate
and
I'm
perfectly
happy
with
a
compartment
API,
at
least
for
now,
in
which
it's
not
popular
possible
to
emulate
that
so.
A
For
the
record,
this
one,
if
we
have
a
way
to
make
it
to
create
it
and
in
a
compartment,
will
be
to
create
a
from
scratch.
We
could
make
it
knock
available.
We
could
make
it
a
getter
and
setter
and
we
could
emulate
the
behavior.
It's
not
really
super
weird
convert
to
other
things
like
Dunkleman
all,
oh.
B
Yeah
document
all
I
also
don't
want
to
be
able
to
emulate
the
thing
if
I
understand
the
concern
with
with
window.
Not
location
is
not
what
the
property
is
like,
what
the
effects
are
of
setting
it,
which
is
you
the
frame,
is
navigated.
You
now
have
a
completely
fresh
set
of
global
variables,
not
global
lexical
birth.
It's
just
the
golden
variables
that
are
supposed
to
correspond
to
properties
on
the
global
object,
but
you
had
the
same
global
object.
The
the
thing
that's
real
fight
as
global.
B
A
F
I
make
one
point
here:
window
dot
location
is
actually
a
little
bit
more
complicated
as
I'm
sure
most
of
us
are
aware
window
dot
location
is
not
simply
a
string,
it's
an
object,
and
so
it
has
a
bunch
of
properties
like
href,
search,
host,
port,
etc.
If
you
start
met,
if
you
start
setting
those
it's
effectively
the
same
thing.
A
F
Me
ask
this:
if
I
may,
is
there
a
shim
on
this,
where
we
could
experiment
and
write
tests
to
see
what
behaviors
actually
happened.
E
F
A
So
on
that
point,
first
on
that
point
location
is
problematic
today,
just
because
it's
non
configurable
and
because
in
a
browser
you
cannot
really
visualize
it,
but
if
we
create
a
neuro
or
a
compartment
where
we
will
be
able
to
define
the
global
descriptors
in
slightly
different
ways,
we
could
make
it.
We
could
visualize
a
we
hate
you
as
you
behave
today
there.
There
will
be
some
ups
ever
what
the
friends
like
it's
not
a
data.
We
are
putting
more
together
and
said
it,
but
is
it
really
a
problem?
The.
E
A
E
I
think
that
that
kind
of
dictates
that
this
property
in
its
proxy,
you
know
it
is
as
addressable
by
the
proxy
itself-
is
really
not
writable.
When
you
try
to
write
it,
you
basically
just
create
a
new
proxy
and
you
put
a
new
location
on
it,
and
you
put
many
new
things,
including
object
from
which
location
on
that
proxy
is.
You
know
inherited
so.
A
E
A
F
What
I
was
trying
to
get
at
for?
The
second
point
is
simply
if
there
was
a
shim
that
we
could
play
with
to
figure
out
okay,
what
are
we
actually
dealing
with
and
write
some
tests
for
it
to
figure
this
out?
That
might
be
helpful
and
I
might
have
just
volunteered
myself
for
that.
Considering
again,
I
have
some
more
time
available
for
this
kind
of
stuff.
So.
E
So
again,
like
I
think
the
best
way
to
try
this
would
be
jeaious
Tom
at
this
point
because
you
could
kind
of
like
do
the
I
want
to
inspect
from
within
and
from
outside
I
believe.
But
it's
been
many
many
years
since
I
looked
at
J's
Dom,
so
I
don't
know
how
up-to-date
they
are,
but
I
know
they
even
have
like
custom
elements
and
yeah.
A
D
F
E
E
C
I'm
I'm,
since
we're
getting
close
to
the
homestretch
here,
I'm
wrapping
up
the
resolutions
that
we
have
from
this
meeting
good.
C
So
so
far,
I'm
just
gonna
read
this
back.
We
convinced
ourselves
that
it
would
be
sufficient
for
the
built
in
modules
proposal
to
use
a
mutation
from
within
mechanism.
The
best
proposal
wouldn't
require
some
additional
verbage
to
lock
down
would
make
the
module
map
immutable.
Built-In
modules
need
to
be
would
need
to
be
petrified
by
the
lock
down,
and
the
compartment
API
would
need
to
clarify,
even
though
it's
implied
already
that
built-in
modules
are
not
implicitly
inherited
by
child
compartments.
C
A
A
A
C
C
It
would
have
to
I
don't.
A
So
for
me,
the
question
is
really:
is
it
an
update,
a
reef,
I'd,
contour
or
update,
or
is
it
a
API
that
you
used
to
interact
with
the
contour
or
is
it
a
hook
that
allow
you
to
intersect
operations
against
the
contour
yeah
and
carry
on
those
operations?
Somehow,
and
it's
in
your
own
userland
code?
Those
are
really
the
three
options
that
I
see
moving
forward.
Yeah.
C
I
think
that
I
think
that
that's
candy
at
this
point,
at
least
for
AG
oryx
motivating
use
cases
evaluate,
is
certainly
sufficient,
but
for
but
for
rebels
and
emulating
other
existing
behaviors
I.
Think
that
we
can.
We
can
revisit
this
as
needed.
I.
A
Remember
when
you
go
to
the
committee
for
a
stage
a
battement,
a
battement,
no
really
a
well
I've
Corinne
use
cases.
Yes,.
C
B
Know,
I
think
that
the
naming
thing
is
is
something
maybe
just
you
and
I
and
Bradley
can
can
just
meet
separately,
because
it's
the
kind
of
endless
bike
sharing
that
has
to
be
settled
but
yeah.
My
guess
is
that
it
doesn't
need
to
be
this
entire
group
that
spends
time
settling
anybody.
Anybody
who
wants
to
join
us
for
that,
but
it
will
be
just
endless
bike
share.