►
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
All
right,
thanks
for
coming,
everyone
looks
like
we
have
three
topics
that
I
know
of
daniel's
here
for
some
internal
slot
discussion.
Leo
has
some
feedback
from
the
chrome
team
and
yulia
has
left
us
with
a
presentation
to
review
and
provide
feedback?
Does
anybody
particularly
wish
to
go
first.
B
It's
pretty
late,
where
I
am
so.
I
wouldn't
mind
going
first.
A
And
we
wouldn't
mind
and
having
you
first
go
ahead:
daniel.
B
So
we
were
talking
about
last
meeting,
or
at
least
the
last
one
that
I
was
at
this
exotic
internal
slot
hazard,
and
I
think
we
came
to
some
interesting
understandings
and
I
want
to
understand
what
the
you
know,
what
our
conclusion
is,
or
next
steps
or
anything
so
mark.
How
do
you
feel
about
this?
This
issue
now.
C
I
am
much
much
much
more
calm
about
the
issue.
I
I
really
learned
a
lot
last
session.
It
was
a
real
number
of
surprises,
in
particular
missing
the
significance
of
maps
as
a
container
of
objects
via
internal
slots,
just
really
kind
of
upended
my
whole
understanding
of
where
we
are
so
so.
C
I
would
say
that
my
conclusions
once
again
I'll
be
speaking
for
myself,
so
other
people
should,
you
know,
feel
free
after
me,
my
conclusions
are
that
it's
still
a
trade-off
and
there's
still
a
hierarchy
of
fallback
positions,
pretty
much
like
I
had
presented
in
the
slideshow,
but
milder
it's
still
better
to
avoid
internal
slots
than
to
add
them,
but
sometimes
we'll
add
them
anyway.
C
If
we
add
them,
it
is
probably
the
single
strongest
recommendation
that
survived
the
last
meeting
is
that
built-in
methods
that
access
internal
slots
should
only
access
internal
slots
on
their
this
argument.
C
And
if
we
do
that,
then,
across
regular
membranes,
a
practical
transparency
is
preserved
without
further
interference
with,
and
then
the
next
fallback
is.
C
If
a
built-in
method
needs
to
be
specified
to
access
an
internal
slot
on
a
non-this
argument,
then
it
would
be
good
if
the
fallback
behavior
of
the
method,
if
the
argument
does
not
have
the
expected
internal
slot-
happens
to
be
one
that
preserves
a
good
measure
of
practical
transparency
in
the
case
where
that
argument
is
instead
a
proxy
for
a
similar
object
on
the
other
side,
and
what
that
what
the
nature
of
that
fallback
behavior
is
will
be
ad
hoc
and
dependent
case
by
case
there's,
nothing
universal
there
and
the
example
that
shows
how
ad
hoc
it
is
is
promise
dot
resolve
operating
on
a
proxy
for
a
promise
does
not
recognize
it
as
a
promise
does
not
therefore
return
it
directly.
C
C
C
With
regard
to
the
fully
transparent
membrane
for
anything
for
any
internal
slot,
it
doesn't
recognize
it's
just
going
to
hide
it.
It's
going
to
be
as
if
it's
not
there
across
the
membrane,
which
is
the
you
know.
The
non-transparency
for
the
odd
case
like
the
date.prototype.gettime.com
and
for
and
as
long
as
those
things
are
hidden
rather
than
some
heroic
effort
to
make
them
appear
through
the
membrane.
C
C
And
those
things
have
to
be
in
bed
with
the
near
membrane.
They
in
the
near
memory
need
to
know
about
each
other
and
have
special
access
to
each
other,
so
they're,
not
so
so.
For
that
case,
they
can't
cannot
be
orthogonal
mechanisms,
and
for
that
case,
since
it
knows
about
the
full
mirror
membrane,
if
it
finds
an
object
rather
than
data,
it
still
has
to
pass
it
through
the
entire
membrane
wrapping
mechanism,
which
presumably
there
is
a
standard
way
to
do
for
any
membrane
just
has
to
act.
C
It
already
has
to
do
that
for
access
to
elements
of
a
map,
so
I
think
in
both
cases
there
is
no
significant
extra
penalty
for
an
internal
slot,
holding
an
object
versus
an
internal
slot,
holding
a
data
holding
data
so
that
so
that's
my
analysis
of
sort
of
the
hierarchy
of
preferences.
B
So
you
know
it's
I
don't
want
to.
I
I
feel,
like
I'm
still
missing
something
I
feel
like
it's
still
hard
for
me
to
conclude
that
these
are
necessary.
Like
for
the
case
of
I
mean
I,
I
like
the
phrasing
of
a
hierarchy
of
preferences,
I
want
to
focus
on
the
things
that
affect
proposals
that
I'm
currently
championing
or
mentoring.
B
So
none
of
the
proposals
that
I'm
currently
championing
or
mentoring
have
instances
of
the
non-this
object
being
a
thing
that
has
internal
slots.
So
I
have
to
say
I'm
not,
I'm
not
yet
convinced
that
the
non
this
case
needs
to
follow
this
property
that
you
articulated,
but
I
want
to
defer
that
discussion
for
another
for
another
day,
when
I
have
a
concrete
proposal
that
I'm
that
I'm
thinking
about,
because
if
it's
in
the
air,
maybe
I'm
getting
myself
confused,
so
I
want
to
focus
on
the
internal
slots
on
the
this
object.
B
So
I'm
thinking
about
two
concrete
proposals.
One
is
intel
segmenter
and
the
other
one,
and
I
guess
I'll
turn
on
the
camera.
If
I'm
talking,
one
one
is
intel
segmenter
and
the
other
one
is
temporal.
Where
both
have
internal
slots
intel
segmenter
has
this
very
simple
internal
slot
that
has
the
segmenter
and
then
it
has
a
getter
to
get
it
in
general,
you
you
mentioned
sort
of
a
desired.
You
might
say
like
a
desirable
thing
of
avoiding
internal
slots
when
possible
and
using
own
properties
when
possible.
B
I
feel
like
the
opposite.
I
feel
like
the
default
should
be
to
use
internal
slots
and
we
should
only
add
overrideable
mechanisms
when
necessary.
So
if
you
were
you
there
at
the
last
tc-39
meeting
when
the
revision
of
array
and
other
standard
library
subclassing
things
was
discussed,
yes
yeah,
so
in
that
presentation
they
discussed
how
adding
points
of
observable
interception
capability,
really
complicated,
implementations
and
led
to
security
issues.
B
B
Because,
internally,
you
don't
use
the
accessor
internally,
you
use
the
internal
slot.
The
accessor
is
used
only
superficially,
so
the
idea
is
that
we
wouldn't
have.
I
was
I
was
imagining
that
we
wouldn't
have
owned
properties
that
are
redundant
with
internal
slots.
I
was
imagining
that
you
would
use
that
own
property
as
the
actual
place
for
data
storage,
but
that
would
create
these
interception
possibilities
if
the
goal
was
to
prevent
the
case,
where
there's
an
object
being
held
inside
the
other
object
at
all
and
prevent
it
from
being
leaked
at
all,
then
you
know
these.
C
So
so
so
you
say
so
let
me
make
sure
I
understand
this,
because
initially
I
thought
my
position
was
that
only
the
getter
and
setter
of
the
accessor
access,
the
internal
slot,
in
which
case
overriding
or
changing
the
accessor
property,
would
seem
to
be
as
interceptable
as
changing
any
normal
property.
C
But
it
sounds
like
what
you're
saying
is
that
there
would
be
other
built-in
methods
that
would
access
the
internal
slot
in
question
without
going
through
the
access
of
property,
in
which
case
we
need
to
examine
those
and
turn
it
as
more
built-in
methods
to
access
the
internal
slot
than
what
their
nature
is.
B
So
that's
what
tends
to
come
up
for
the
proposals,
I'm
aware
of
that.
These
properties
exist
because
they're
used
by
the
other
algorithms
and
so
making
it
so
that
those
other
algorithms
had
have
to
instead
do
a
property
access
opens
up
to
all
this
extra.
It
opens
up
to
violation
of
any
sort
of
invariant
that
you
would
have
about
the
confidence.
C
I'm
not
at
this
point
objecting
to
that.
What
I'm
pointing
out
is
that
the
implication
of
what
you're
saying
is
that
the
set
of
built-in
methods
that
access
internal
slots
that
are
coming
with
this
proposal
is
more
than
just
the
built-in
getters
and
setters
of
the
access.
So
we
need
to
take
a
look
at
what
those
other
methods
are.
B
So
I
you
know
this:
this
becomes
difficult
for
me
because
I
really
want
to
find
a
simple
right
set
of
recommendations
that
we
can
give
to
proposal
authors.
I
don't
think
it
will
be
scalable
for
all
proposal,
authors
to
come
to
this
meeting
to
negotiate
the
relative
tradeoffs.
I
want
to
have
a
simple
set
of
rules
that
we
can
apply
universally
because
I
think
otherwise
it's
just
not
going
to
be
practical.
It's
not
going
to
scale
to
like.
We
have
benefits
from
expanding
the
javascript
standard
library.
B
B
C
Okay,
so
if
we're
stipulating
that
we're
only
talking
about
internal
sloths
of
this
argument,
then
with
regard
to
the
the
transparent
membrane,
it's
simply
expanding
the
number
of
concrete
cases
where
you
lose
full
transparency
without
at
all,
adding
to
the
cases
where
you
lose
practical
transparency
and
the
cases
and
kind
of
of
full
transparency
you're
losing
is
one
for
which
there's
already
lots
of
precedent.
C
C
B
Pretty
strongly
that
full
transparency
in
this
way
that
you're
articulating
it
doesn't
make
sense
to
hold
up
as
a
goal
for
new
proposals,
the
practical
transparency.
I
I
understand-
and
I
I
like
to
think
that
that
the
proposals
that
I'm
working
on
meet
that
I
mean
I'd
like
to
understand
if
they
don't
but
the
full
transparency
gold,
because
it's
so
consistently
violated
by
everything,
doesn't
make
sense
to
me
as
a
thing
for
us
to
keep
referring
to
as
like
a
lens.
C
So
so
I
so,
I
will
state
that
I
still
have
a
preference
to
avoid
internal
slots
for
reasons
that
I've
explained
and-
and
I
you
know
I
will
continue
to
you-
know-
act
in
accord
with
that
preference
unless
I'm,
unless
somebody
convinces
me
otherwise.
C
But
like
like,
I
also
said
it's
a
mild
at
this
point
for
the
foot
for
the
full
membrane.
It's
a
mild
preference,
the
the
stronger
issue
for
which
caridian
richard
can
probably
speak
in
a
more
informed
way
than
I
can
is
for
the
near
membrane.
C
Agorak
is
not
planning
to
build
a
near
membrane,
so
this
is
not
pressing
for
us,
but
salesforce
is
you
know
their
whole
infrastructure
at
this
point
depends
on
the
near
membrane
and
for
near
membrane,
whether
it's
on
a
this
or
not
in
both
cases,
every
method
that
accesses
an
exotic
internal
slot
must
be
monkey
patched
with
this
thing,
that's
that
that
that
has
special
privilege
with
regard
to
the
between
so.
B
B
C
I
I
am
in
favor
of
that
policy
and
I'm
also
in
favor
of
letting
kurdi
be
the
main
ones.
Speaking
for
the
interests
of
near
membranes.
If
I've
got
the
interest
of
near
membranes
wrong,
I'll
I'll,
probably
defer
to
correct.
B
Okay,
just
for
for
information
accurately
is.
C
So
for
near
membranes,
I
don't
think
it
makes
a
difference
whether
it's
on
the
disc
or
not,
for
the
practical
transparency
through
full
membranes
through
the
normal
membranes,
the
this
versus
non.
This
makes
a
huge
difference.
I
don't
think
it
makes
a
difference,
so
I.
B
C
If
the
entire
invocation
naturally
ends
up
on
the
other
side
of
the
membrane,
then
you're
fine,
but
normal,
for
when
the
when
the
object
that
might
be
a
proxy
is
a
non.
This
then,
typically,
the
invocation
won't
be
passed
through
the
membrane
because
you
might
be
like
promise.resolve
is
a
great
example,
is
you're,
saying
to
your
local
promise,
constructor,
which
is
on
your
side
of
the
membrane
dot
resolve
on
a
proxy
for
a
promise.
C
That's
on
the
other
side
of
the
membrane-
and
I
think
you
know
all
of
the
non-disk
cases
were
like
that,
where,
if
the
receiver
of
the
operation,
if
you
sort
of
the
initiator
of
the
operation,
is
on
your
side
of
the
membrane,
then
the
invocation
will
happen
on
your
side
of
the
membrane,
with
the
argument
being
a
proxy
for
something
on
the
other
side.
C
The
reason
why
this
argument
is
interesting
is
because,
since
you're
fetching
the
method
on
the
typical
case
from
the
list,
the
method
will
typically
also
be
a
proxy
for
the
method
on
the
other
side
of
the
membrane.
So
that's
exactly
the
case
where
the
indication
ends
up
on
the
other
side
and
you
get
the
unwrapping.
B
Okay,
thanks
for
explaining,
so
that
that
helps
me
to
understand,
and
if
I
run
into
a
case
where
that
causes
problems,
then
I'll
come
back
to
you
so
that
we
can
discuss
it.
My
takeaway
for
things
like
intel,
segmenter
and
temporal,
is
that,
because
all
of
the
internal
slot
access
happens
on
this
values,
as
far
as
I
know,
we're
safe
to
continue
to
you
to
put
objects
in
those
places
and
yeah
yeah.
B
I
don't
really
know
what
I
I
mean
you've
mentioned
that
you
prefer
avoiding
internal
slots,
but
I
still
feel
like
the
default
preference
for
for
proposals
just
so
they
can
maintain
invariants
about
maintain
internal
structure
about
how
they're,
using
their
their
things,
that
if,
if
some
data
is
going
to
be
used
for
some
internal
algorithm,
then
the
default
should
be
to
hold
it
in
an
internal
slot.
C
So
I
am
not
worried.
I
am
not
at
this
point
willing
to
agree
that
that
should
be
the
default.
C
However,
my
preference
in
the
other
direction
is
mild,
so
I'm
willing
to
look
at
the
trade-offs
in
any
individual
case
with
regard
to
having
a
general
policy
that
covers
cases
that
we
haven't
actually
looked
at
specifically
such
as
the
other
methods
in
question
that
access
the
internal
slots
directly
besides
the
getter
and
center.
C
D
B
B
C
Okay
is
the
current
state
of
the
proposal,
one
that
contains
the
internal
slots
that
we're
discussing.
B
B
E
D
B
So
what
do
you
could
you
describe
your
use
of
them
and
what
you
need
from
out
of
this
out
of
you
know.
Mark
has
been
talking
about
how,
if
we
add
certain
things
to
the
javascript
standard
library,
they
wouldn't
work
well
with
salesforce's
use
of
near
membranes,
and
I
want
to
understand
what
that
would
mean
in
practice.
E
E
How
can
we
note
out
any
intrinsic
from
the
realm
by
eliminating
all
the
ways
that
they
can
have
to
walk
the
prototype
chain
and
then
pretty
much
doing
a
little
bit
of
patching
on
the
rom
to
eliminate
everything
and
get
eliminate
the
identity,
discontinuity
problem
between
the
two
realms
and
we'll
have
some
feedback
on
that
soon,
probably
a
couple
of
weeks
or
so
we'll
have
some
feedback,
I'm
optimistic
about
this
one
in
terms
of
how
we
use
it
today.
E
E
The
first
one
is
a
very
interesting
one
is
a
I
don't
know
you're
familiar
with
the
shadow
dome
semantics,
but
there
are
many
tools
out
there
like
including
google
tag
manager
or
pando,
or
every
gauge
or
any
library
that
any
any
product
that
gives
you.
This
script
tag
that
you
drop
in
the
page
and
it
understand
the
entire
page.
You
know
this,
you
understand
the
the
structure
of
the
page.
E
It
collects
some
information
about
the
user
interactions
with
the
page
and
then
send
that
over
to
some
server,
some
beacon
or
something
that
collects
that
information
and
show
it
to
you,
that's
a
think
about
google
analytics
or
any
other
tool
that
collects
that
kind
of
information,
all
these
tools
they
have
us
today.
They
have
very
big
issues
with
shadow,
because
the
shadow
provides
this
encapsulation.
E
Where
you
don't
see
what
is
inside
the
shadow,
especially
if
the
shadow
is
closed,
you
don't
see
anything
inside
and
even
if
the
shadow
is
open,
you
lose
some
of
the
information
as
the
events
propagate
with
the
retargeting
of
the
event
and
such,
and
this
is
a
thing
that
you
want
to
have
the
encapsulation.
You
want
to
have,
but
if
having
a
calculation
automatically
breaks
tools
like
google
attack
manager,
then
you
have
a
bigger
issue.
E
One
thing
that
we
figure
out
is
that
well,
if
we
use
virtualization,
we
can
create
this
new
realm.
We
can
do
all
the
work
to
get
this
rom
to
pretty
much
encapsulate
the
functionality
of
the
main
ground,
which
is
the
window.
E
We
use
the
evaluator
inside
that
newly
created
rom
to
be
able
to
evaluate
those
libraries
there
and
we
make
distortions.
So
these
libraries
when
executed,
they
don't
see
the
dom
as
a
composition
of
shadows.
They
see
it
as
a
flattened
tree.
Therefore
they
will
be
able
to
traverse
and
tie
a
dome
up
and
down
and
do
all
kind
of
things.
E
Yes,
you
are
bypassing
the
encapsulation
of
the
shadow,
but
you
do
so
so
you
can
keep
using
these
all
tools
that
are
not
designed
for
the
shadow
encapsulation
and
even
if
they
were
changed
and
we
have.
E
E
Some
trickery
there
in
order
to
give
the
impression
that
you're
actually
running
this
script
in
the
main
page
but
you're
running
in
this
virtual
environment
that
whose
job
is
to
simply
give
you
a
different
reality
of
what
is
really
there,
giving
you
the
flattened
tree
perception
of
the
dome
rather
than
the
encapsulation.
That's
one
use
case,
and
it
automatically
enables
us
to
use
all
these
tools
and
no
penalties
yeah.
They
run
a
little
bit
slower
because
it's
a
membrane
sure.
But
aside
from
that,
is
it's
good
enough
for
getting
all
these
tools
to
function?
E
That's
one
thing.
The
other
thing
that
we
do
is
like.
We
use
this
for
virtualizing
the
the
name
spaces
as
we
call
it
self-worth,
which
is
basically
imagine
a
npm
package
that
contains
x
amount
of
components.
E
So
you
have
multiple
of
these
npm
packages
that
has
different
components,
and
then
you
compose
them
all
together
in
a
page
to
form
the
application
and
we
want
to
have
certain
boundaries
in
terms
of
integrity.
So,
first
of
all,
we
don't
want
any
of
these
packages
to
change
any
prototype
from
the
dome
or
from
the
the
language
itself.
E
So
the
integrity
aspect
of
it
is.
We
want
to
preserve
the
integrity
of
the
platform
code.
The
platform
code
runs
in
the
main
window.
It
is
a
code
that
we
maintain
and
we
don't
want
any
of
this
npm
package
to
actually
change
any
of
the
behavior
there.
E
So
by
creating
these
sandboxes
that
virtualize
environment,
they
have
the
exact
same
capabilities
of
of
the
system
of
the
of
the
window,
but
with
the
assumptions
that
the
integrity
of
the
other
window,
intrinsics
and
dom
apis
and
platform
apis
will
not
be
compromised
from
the
integrity
point
of
view.
E
You
will
not
be
able
to
change
array
prototype
basically,
and
if
you
change
it
so
sorry,
you
would
be
able
to
change
the
array
prototype,
but
that
change
will
only
affect
your
sandbox,
your
virtual
environment.
It
will
not
affect
the
other
one.
We
first
try
to
not
allow
you
to
to
change
that,
but
that
breaks
a
lot
of
code
so
freezing
or
not
allowing
you
to
change
the
array.
Prototype
filter
is
just
not
an
option
for
us,
because
we
have
so
much
code
right
now.
E
That
is
doing
that
kind
of
silly
patching
and
talking
about
that,
but
it
could
be
anything
so.
By
introducing
this
near
membrane,
we
provide
this
extra
layer
that
controls
the
integrity
of
the
of
these
api.
So
whatever
they
do,
they
see
it,
they
interact
with
it.
They
see
the
side
effects
of
their
changes,
but
it
doesn't
affect
any
of
the
other
sandboxes,
neither
the
the
main
window
integrity
and
that's
the
majority
of
the
the
biggest
use
case
that
we
have
for
this.
E
Just
let's
make
sure
that
no
one
mess
with
your
code
in
terms
of
integrity,
no
one
will
change
something
that
might
affect
the
entire
page
or
any
other
sandbox.
So
that's
how
we
use
it
and
then,
aside
from
that,
we
use
it
for
extra
distortions
on
this
different
sound
boxes,
but
that's
just
a
extra
thing
like,
for
example,
we
do
segmentation
of
the
cookies
or
we
do.
E
E
B
Yeah,
these
are
really
interesting
applications.
Can
you
say
more
about
what
you
mean
by
near
membrane
in
salesforce's
case.
E
Yeah,
for
the
new
membrane
for
soft
force
case
is
just
a
membrane
that
whose
job
is
to
emulate
or
or
provide
the
same
capabilities
of
the
actually
actual
realm
that
you
want
to
emulate,
with
the
capabilities
of
preserving
the
integrity
of
the
optograph
in
the
in
the
original
realm.
So
yeah.
B
E
Yeah
everything
is
a
proxy
yeah.
At
that
point,
everything
is
a
proxy,
so
the
identity
is
important
in
the
near
membrane,
because
you're
emulating
the
the
interaction
with
the
with
the
realm,
and
that's
part
of
this
deal
like.
If,
if
I
run
my
code
in
the
main
window,
it
works
the
exact
same
way.
If
I
run
it
inside
the
sandbox,
I
see
no
observable
difference
there,
assuming
that
you're
not
making
any
changes
in
the
in
the
prototype
and
all
that
the
code
is
exactly
work.
E
B
E
I
see
a
date
on
the
other
side
and
they
should
see
they
should
be
no
identity
problem
that
you
would
not
see
if
you
run
all
the
code.
In
the
same
realm,
the
identity.
E
C
Yeah,
like
I
would
like
to
clarify
some
things
and
greedy,
please
catch
me
if
I'm
clarifying
wrong
the
given
that
any
one
object
is
only
on
one
side
of
the
membrane
or
the
other.
Given
that
there's
no
object
where
the
actual
object
is
on
both
sides,
then
you
can't
compare
an
object
to
one
side
of
the
membrane
using
triple
equal
with
an
object
on
the
other
side
and
the
membrane
mechanism
that
both
near
membranes
and
full
membranes
use
is
they
use
a
weak
mat.
C
They
use
weak
maps
in
order
to
create
what
we
call
an
identity,
preserving
their
brain,
so
that
the
identities
on
one
side
are
mapped
one
to
one
with
identities.
On
the
other
side,
so
nobody
can
observe
an
identity
difference
with
regard
to
object,
identity,
but
the
further
thing
is
kuri's
definition
of
near
membrane.
C
C
C
B
Pass
a
date
over
salesforce's
membrane
garrity.
Do
you
get
a
date?
Do
you
get
a
proxy
or
you
get
a
date
with
internal
slots
like
directly?
Do
you
get
a
different
copy
of
the
same
date?
Do
you
just
get
sort
of
that
that
thing
unmodified,
because
it
doesn't
have
any
particular
powers
or
how?
What
does
it
do.
E
Oh
sorry,
so
it's
really
about
so
a
couple
of
things
mark
what
I
was
trying
to
explain
that,
from
the
perspective
of,
if
you
run
the
same
code
without
the
membrane
and
you
run
it
in
the
in
the
main
realm
is
very,
is
very
in
a
regular
membrane.
E
You
might
have
problems
if
you're
checking
the
identity,
because
you
will
see
the
same
identity
for
everything
while,
if
you
insert
the
membrane
in
between
the
identity
of
those
objects,
changes
and
in
the
near
membrane,
it
doesn't
matter
if
you
run
it
all
of
them
in
the
same
problem
or
separate,
the
identity
is
the
same,
so
the
code
should
be
behaving
the
same.
I
think
that
that's
another
way
to
explain
the
same
that
you
were
saying
like.
We
still
need
to
figure
out
how
how
to
articulate
this
better.
C
I
think
I
think
that
the
you're
making
it
sound,
like
the
full
membrane,
is
introducing
a
non-transparency,
an
identity,
discontinuity
and
if
the
scenario
you're
starting
with,
is
interacting
across
a
round
boundary,
then
you
already
have
the
same
identities,
because
the
round
boundary-
and
my
claim
is
that
the
normal
membrane
is
practically
transparent
as
something
inserted
between
two
realms
that
it's
that
that
it's
not
introducing
new
identities
continuities
beyond
the
ones
that
around
boundary
already
has.
Except
for
these
odd
cases
like
date.prototype.gettime.com,.
E
Okay,
so
daniel
in
terms
of
your
specific
question,
it
depends
of
the
research
that
we're
doing
right
now,
so
we
have
explored
different
options.
One
option
is
well:
it
gets
remapped
to
the
prototype
chain
on
the
other
side
and
because
it
gets
remapped
to
the
prototype
chain.
E
On
the
other
side
that,
if
you
try
to
get
something
out
of
the
date,
you
will
try
to
look
into
the
actual
object,
which
is
a
proxy
and
then
it
will
fail,
because
the
intent
of
the
date
is
going
to
be
a
proxy,
but
his
prototype
will
be
the
prototype
of
the
specific
rom,
that's
interacting
with
it,
and
that
will
fail
to
get
any
access
to
any
of
the
internet
slot
that
that
breaks.
The
second
option
is
that,
well
you
you
put
a
proxy
around
it
and
you
don't
up
the
prototype.
E
E
E
Then
we
should
be
fine,
because
if
you
attempt
to
create
a
date,
you're
really
creating
a
date
on
the
outer
window
in
the
other
realm
and
then
what
you
see
in
your
site
is
really
a
proxy
of
it
and
it's
a
proxy
membrane.
So
every
operation
with
it
will
go
into
the
other
one.
So
the
identity
is
the
same.
E
Obviously,
because
all
the
dates
are
coming
from
the
same
realm,
but
for
that
we
need
to
guarantee
that
you
will
never
be
able
to
create
an
intense
whose
prototype
whose
observable
prototype
is
is
coming
from
from
this
software
or
sandbox
round.
Right
now
we
are,
we
are
in
the
in
the
in
the
second
step,
where
what
you
get
is
a
proxy
of
the
date
and
you
interact
with
it
directly.
But
if
you
check
the
interns
up,
it
fails
so
there's
identity
disconnected
there
as
the
best
we
can
do
at
the
moment.
E
A
combination
of
it
because
for
some
cases
like
the
object,
arrays
and
functions,
we
do
linear
membrane
for
all
the
other
things
we
do
a
regular
membrane.
B
D
C
Make
sure
I
understand
you're
doing
a
regular
membrane
but
you're
not
using
any
local
equivalence
of
the
foreign
objects
you're
using
a
regular
membrane,
but
you're
not
experiencing
identity.
Discontinuity
because
you're
only
using,
for
example,
remote
dates,
you're,
never
using
a
local
date
in
the
same
universe
in
which
you're
using
a
remote
date,
and
that's
where
the
undeniables
come
in
is
the
things
that
are
not
undeniable.
Like
date,
are
the
ones
where
you
can
get
away
with
that.
The
things
that
have
undeniable
like
array
are
the
ones
where
you
have
to
do.
E
Right,
the
big.
The
big
example
for
us
is
promise
the
async
away
kind
of
thing.
It
produces
a
promise
whose
prototype
is
the
promised
prototype
of
the
sandbox,
the
realm
in
the
sandbox
and
that
breaks,
because
even
if
we
change
the
global
promise
to
map
to
the
proxy
on
the
on
the
other
side,
sometimes
you
will
get
this
object
whose
prototype
doesn't
match
that
and
we
have
no
way
to
control
that.
E
So
we
have
been
struggling
with
that,
but
I
I
hope
that
we
can
solve
it
with
this.
The
trick
of
changing
the
the
pro
the
pro
or
controlling
the
prototype
axis.
E
Yeah,
well,
we
for
promises,
so
array
function
and
objects,
because,
as
you
call
it,
I
think
you
call
it.
What
was
the
term
that
you
used
the
generic
operations?
E
Those
are
fine
in
the
case
of
the
promise.
We
do
the
replacement
of
the
global
promise
with
the
proxy
of
the
outer
promise.
We
do
that
one.
So
you
create
promises
manually
and
all
that
that's
the
way
it
works.
It
works
pretty
well,
but
it
falls
short
when
you
are
using
async
await,
because
if
you
use
it
you're
declaring
a
function
that
returns
a
promise
and
that
is
implicit
in
terms
of
you-
never
really
use
the
global
promise
for
any
of
these,
but
it
returns.
A
promise
then
fails
like
that.
C
I
would
would
have
expected
you
just
to
do
the
full
near
membrane,
trick
on
promises
where
you
map
the
prototype
on
one
side
to
the
prototype
on
the
other
side
and
where
you
take
all
built-in
methods
that
access
the
promise
internal
slots
and
replace
them
with
these
ones
that
are
privileged
with
regard
to
the
near
membrane,
in
order
to
operate
on
proxy
for
a
promise
as
if
it
was
a
promise.
That's
what
that's?
That's!
E
Right
that
was
one
of
the
things
that
we
tried,
but
then
it
breaks
because
the
promise
that
I
receive,
because
I
need
to
put
a
proxy
around
the
entrance
but
using
my
own
prototype.
He
fails
because
it
doesn't
get
any
of
the
general
slots.
C
But
you're,
but
if
you're,
let's
take
an
example
of
then
as
as
an
example,
actually
I'm
not
sure
if
then
yeah.
No,
that
must
be
an
example.
C
If
what
I
would
expect
you
to
do
as
part
of
the
whole
near
membrane
architecture
is
to
say,
because
then
is
part
of
an
undeniable
abstraction
and
because
it
accesses
an
internal
slot,
we
must
replace
the
built-in
then
method
with
one
that
is
near
membrane,
aware,
so
that
if
then
is
operating
on
a
near-membrane
proxy,
rather
than
a
promise
that
it
uses
its
special
privilege
with
regard
to
the
near
membrane,
to
instead
invoke
the
then
behavior
on
the
other
side
of
the
membrane.
E
Yes,
but
that
has
a
a
very
tricky
side
effect,
which
is
that
the
others,
the
the
this
is
a
one
avenue
when
you
get
a
promise
from
outside
from
the
outer
row,
and
then
you
see
it
inside
when
you
generate
a
promise
for
an
inside,
whether
from
syntax
or
by
creating
a
promise
with
your
own
promised
prototype,
and
you
share
it
with
the
outs
outside.
E
You
have
to
also
patch
the
outside
right
and
so
patching
the
outside
becomes
a
lot
more
complicated
because
you
have
a
one
too
many
relationship
between
the
different
sandboxes
that
you
have
the
different
membranes
that
we
create.
So
it
creates
a
lot
more
complexity
for
us.
So
what
we
we
try
that
didn't
work
that
well
for
us.
We
were
having
struggling
here
and
there.
So
what
we're
doing
right
now
is
what
I
described
like.
E
We
just
replaced
the
global
promise,
and
then
we
transpile
the
the
we
transpile
the
the
async
await
in
ways
that
we
that
we
can
actually
wrap
it
into
the
actual
promise
that
is
coming
through
the
membrane
as
a
proxy,
and
by
doing
that,
then
all
the
promises
that
we
produce.
They
all
have
the
same
identity
everywhere.
B
Wait
so,
but
it's
sorry
chris,
are
you
raising
your
hand.
F
I
I've
been
trying
to
get
a
question
in
edgewise
for
about
15
minutes.
It's
it's
very
simple.
It
may
be
a
little
bit
of
a
tangent,
but
it's
just
I'm
just
having
trouble
understanding
something
and
I'm
a
little
confused
by
the
term
near
membrane
and
just
a
quick
question
is:
when
is
the
word
near
in
your
memory
near
as
in
contrasted
with
far
or
nearer,
as
in
almost
like
near
beer.
C
No,
as
contrasted
with
far
the
idea
is
that
it
makes
remote
objects
appear
to
be
local
where
remote
and
local
means
in
the
different
realm
versus
verses.
In
the
same
realm,
got
it
thanks
so
coridia
a
question
for
you.
It
sounds
like
the
trick
that
I
associated
as
sort
of
fundamental
to
the
notion
of
a
near
membrane,
which
is
this
monkey
patching
of
the
built-ins
that
access
internal
slots
to
do
this
privileged
access
through
the
near
membrane,
it
says,
are
you
it
sounds
like
you're
not
doing
that
at
all
anymore.
E
Yeah,
that's
correct,
yeah,
it's
just
because
of
that
one
too
many,
it's
just
too
complicated,
because
we
have
to
have
a
weak
map
that
is
a
global,
weak
map.
So
remember
we
talked
about
having
membranes
with
the
marshall,
where
the
mantra
controls
all
these
different
areas
and
different
environments
that
you
create
or
realms
that
you
create.
E
So
the
marshall
now
has
to
keep
track
of
every
every
proxy
everywhere
and
all
the
identities
all
these
things,
and
it
just
becomes
a
lot
more
complicated
for
us
and
just
that's
why
I
really
like
the
idea
of
nulling
out
all
the
intrinsics
from
the
sandbox,
which
we
really
use
evaluator
only
and
then
even
for
objects
arrayed
on
prototype.
We
might
I
mean
up
the
array
and
function
prototypes.
We
might
also
do
the
remapping
entirely
there
as
well.
E
If,
if,
if
it's
performance
enough,
I
don't
think
it
will,
but
it's
another
area
to
explore,
but
first
all
the
things
that
are
not
that
are
not
doing
generic
operations.
We
have
to
figure
ways
to
make
them
proxies,
and
then
we
can
proceed
to
the
object,
our
rate
and
function
if
we
need
to.
But
that's
why
we
we're
investing
heavily
on
that
right
now
to
try
to
get
to
the
point
where,
where
we
say:
okay,
this
this
actually
works.
We
control
the
prototype
axis.
We
control
everything.
D
E
B
Oh,
that,
that's
really
interesting.
So
one
of
my
takeaways
is
it's
a
really
big
deal
to
add
more
undeniables
and
the
record
and
temple
proposal
does
add
two
undeniables
temple
prototype
and
record
prototype,
and
I'm
not
sure
what
kind
of
analysis
we
should
do,
but
probably
we
should
cue
that
to
do
at
some
point.
B
My
other
takeaway
is
that
if
this
monkey
patching
technique
that
we
previously
discussed
turns
out
to
be
inviable,
it
sounds
like
aside
from
the
undeniable
issue,
things
that
are
not
undeniable:
it
it
bottoms
out
into
the
same.
You
know
full
membrane
case
that
we
already
knew
how
to.
C
It's
actually
easier
than
the
brain
case,
because
you're
only
computing
across
the
membrane
you're,
not
mixing
so
right,
I
think
so.
I
think
what
that
means.
The
conclusion
that
I
think
I'm
drawing
is
that
for
the
non-undeniable
case,
the
internal
slots
just
don't
make
any
difference
at
all.
E
I
think
that's
accurate
because
you
can
always
replace
the
the
global
and
make
it
a
proxy
and
then
that's
fine
you're
out
of
the
woods.
But
if
it
is
undeniable,
then
you
have
either
to
determine
if,
if
it's
a
generic
operation
or
is
a
operation
that
use
internal
slots,
that's
a
differentiator
there,
and
if
it
is
a
generic
one,
then
it's
fine,
you
remap
it
and
it
just
works.
If
it
is
using
internal
slots,
then
you
have
to
figure
other
ways
to
either
neutral
that
or
patch
it
everywhere.
E
Yes,
so
we
have
the
issue
with
with
errors,
for
example
like
when
you
throw
an
error
or
you
have
a
syntax
error
or
whatever
what
you
get
on
on
the
other
side
will
be.
The
error
object
whose
prototype
is
the
error.
Prototype
well,
error
is
not
something
that
you
can
generate
from
syntax,
but
a
typo,
something
that
you
can
generate
from
syntax.
E
What
you
get
on
the
on
the
color
would
be
a
error,
a
type
error
whose
prototype
is
type
error,
prototype
from
that
sandbox
and
and
now
you
have
to
figure
out
how
to
remap
that
to
the
type
error
on
the
other
side,
so
you
can
check
the
identity
of
it
and
so
on.
So
it's.
E
B
So
I
wouldn't,
if
people
are
available
for
it,
I'd
want
to
talk
through
the
case
of
record
prototype
and
temple
prototype
since
they're
new
undeniables
that
we're
proposing
in
the
in
the
record
and
temple
proposal.
B
Those
those
are
just
ordinary
objects
that
have
a
bunch
of
methods
on
them
and
they're
mutable
like
normal
things,
and
so
would
those
work
out
fine
to
patch.
Or
do
you
see
risk
in
adding
those
sorts
of
things.
C
D
C
Because
this
is
the
practical
transparency
across
a
full
membrane,
which
is,
if
the
method
only
unboxes
this,
then
when
you
access
the
method
using
dot
on
something
from
the
foreign
realm.
C
Let's
say
for
if
you
have
a
local
proxy
for
a
remote
wrapper-
and
you
say
I'm
down,
what's
like,
actually
just
if
you
say
to
your
proxy
dot,
foo,
open
prayer
and
close
program
where
foo
is
one
of
these
special
built-in
methods
on
you
know
tuple.prototype
that
accesses
the
internal
slot
on
this,
because
you
accept,
because
you
fetch
the
method
starting
from
the
receiver.
C
The
method
that
you
get
that
you'll
be
invoking
will
also
be
a
proxy
for
the
remote
method
and
everything's
fine
if
it
accesses
the
internal
spot
on
a
on
a
non.
This
argument,
then,
if
the
receiver,
the
the
the
method
that
you're
invoking
is
on,
is
is
here,
but
the
argument
you're
invoking
it
on
is
a
proxy
for
a
rapper.
On
the
other
side,
then
you'll
fail.
E
Records
and
sorry,
no,
it's
a
question
for
you
daniel.
Are
you
sure
that
it
doesn't
use
any
argument
like
if
you're
trying
to
compare
records-
or
I
I
don't
remember
the
entire
api,
but
if
you
ever
pass
a
record
as
a
argument
to
a
method
of
another
record
or
something
like
that
we
might
fit
in
we
might
get
into
this
issue.
That
mark
is
trying
to
describe.
G
B
So
one
one
case
that
it
might
appear,
as
is
things
like
json.stringify,
which,
if
it's
passed
a
record
wrapper,
will
unwrap
that
this
is
not
essential
functionality,
but
it's
proposed
to
be
added
for
transparency
with
other
all
the
primitive
wrappers
are
unwrapped,
however,
the
I
wanna.
I
want
to
point
out
that
the
record
and
temple
primitive
wrappers
are
especially
sort
of
remapping
friendly,
because
the
wrapper
objects
are
frozen.
B
They
can't
have
additional
properties
added
to
them,
so
they
just
have
their
internal
slot,
which
is
the
you
know,
the
record
data
or
the
tuple
data.
So
you
could
make
a
new
wrapper
on
the
other
side.
That's
the
local
one.
I
don't
know
if
people
would
want
to
do
that,
but
there.
So
there
is
something
like
json.stringify,
which
also
which
unwraps
the
record,
while
not
being
the
this.
E
So
I'm
confused,
because
is
so
I
I
was
on
the
assumption
that
records
on
tuple
would
be
more
similar
to
symbols
than
actual
objects
in
terms
of
for
membranes
to
operate
on
them.
B
For
yeah
they're
they're
similar
to
symbols,
so
if
you
have
the
primitive,
if
you
have
the
normal
value,
the
membrane
doesn't
touch
it,
but
if
you
have
the
wrapper,
the
membrane,
could
you
know
simple.
Wrappers
are
also
on
well,
no,
not
symbol.
Wrappers,
but
like
number
rappers
are
also
unwrapped
by
json
stringify.
B
C
E
E
B
Function
and
you
call
the
week
you
call
it
with
the
receiver,
I
mean
you
need
access
to
the
dot
call
method.
The
other
thing
that
you
could
the?
Oh,
no
you
don't
you
don't
need
access
to
the
call
method,
because
you
could.
E
B
D
B
Could
you
could,
because
you
could
make
a
symbol
name?
You
could
make
a
property
on
temple
prototype,
which
is
a
a
sloppy
mode
method
and
then
just
call
that
on
a
tuple.
B
G
C
E
G
C
E
Right,
that's
because
jason
stringified
is
looking
up
on
the
arguments
and
try
to
get
antenna
slots
out
of
them.
C
You're
only
going
to
see
the
primitives,
that's
true,
that's
true
in
general,
you
so
so
with
so
once
I
introduce
this
terminology
of
practical
versus
odd
cases,
the
you
know
there's
you
know
this
perpetual
issue
of
how
far
to
stretch
that
category-
and
you
know
so
far.
I've
been
thinking
about
things
like
date.prototype.gettime.com
as
the
odd
case,
whereas
things
like
array
is.
C
As
being
a
normal
case,
similarly
json.stringify
of
something
remote
is
a
normal
case,
and
the
issue
about
rappers,
which
side
of
the
divide
to
put
them
on
just
hasn't,
come
up
before
and
yes,
we
decide
that
all
rappers
are
awed
by
this
classification
that
they're
outside
what
we
mean
by
practical,
then
you're,
correct,
and
I
think
that's
a
that's.
A
very
plausible
position.
A
Yeah
there's
a
question
timing,
point
of
order
for
the
meeting
we're
at
2
13
an
hour
and
13
minutes
in
we
have
two
more
topics
I
think
one
of
them
leo.
I
assume
that
your
feedback
from
the
chrome
team
can
be
deferred
to
the
next
meeting.
If
necessary,
though,
I
think
that
that
should
be
brief
enough
that
I
would
like
to
fit
that
in
and
then
we
also
do
have
julia
presentation
that
we
probably,
I
think,
is
time
sensitive
and
we
should
reserve
some
time.
G
So
I
I've
actually
sized
up
the
issue
by
removing
the
getter
completely
it's
it's
not
necessary.
It
feels
a
little
bit
odd
and-
and
there
are
other
ways
to
access.
C
E
C
Okay,
I
think
the
answer
I
think
the
conclusion
from
this
analysis
is
yeah
go
for
it.
E
Mark
I
I
based
on
the
chat,
the
json35,
so
it
is
what
you
were
saying.
C
Okay,
so
so
yeah
we
could
take.
We,
I
mean
it's
certainly
plausible
what
richard
said
that
we
just
say
that
calling
new
number
puts
the
code
already
into
the
odd
case.
That's
outside
what
we
mean
by
practical
transparency,
and
you
certainly
write
that
that's
much
more
rarer
than
doing
a
dot
caller.apply
on
a
method.
That's
looked
up
by
other
names.
G
Isn't?
Sorry,
isn't
that
still
consistent
with
transparency.
D
Because
I
would
expect
cross-realm
you've
got
two
different
number
rappers
and
json
that
stringify
on
one
side
of
the
realm
for
a
number
on
the
other
side.
Would
you
expect
that
the
the
one
realm
stringify
has
internal
access.
C
Is
that
built-in
methods
recognizing
internal
slots
has
has,
in
all
cases,
that
I
know
of
been
completely
cross
realm,
that
it
doesn't
matter
whether
the
internal
slot
is
from
a
local
or
remote
object?.
G
D
E
C
Yeah,
michael,
if
if
it
did
operate
in
general
in
a
real
local
manner,
then
the
then
normal
membranes
would
actually
be
fully
transparent.
We
wouldn't
have
to
say
because
that
would
mean
the
date.prototype.gettime.
C
A
Let's,
let's
start
with
julia's
presentation,
I'd
like
to
do
I
I
I
I
can
share
my
screen
and
run
the
presentation
as
an
advancer.
Would
anybody
like
to
take
notes,
because
I
think
that
the
this
exercise
is
mostly
for
providing
feedback
for
the.
A
Okie
doke,
it
might
be
good
for
another
person
to
help
out
in
case
there's
too
much
to
quickly
summarize,
but
documenting.
Invariance
is
the
presentation
that
julie
is
prepared
for
the
next
tc
39,
which
I
think
is
soon.
A
I
do
not
know
what
she
intends
to
say
on
each
of
these
slides,
but
let's
go
through
it.
C
C
So
I
think
that
there's
a.
C
I
think
there's
a
terminology
issue
here,
which
is
the:
what
does
it
mean
for
an
invariant
to
be
adopted
and
the?
So
so
because
of
the
terminology,
I
think
what
she
means
by
an
invariant
is
something
that's
accepted
as
something
to
be
written
down
in
the
spec
as
normative,
but
then
it
says,
undocumented
invariants
are
sometimes
overlooked.
C
So
I'm
not
sure
I
mean
the
way
I've
been
using
the
term
invariant
is
you
know
a
proposition
that
happens
to
be
true
across
the
spec
right
now,
whether
intended
or
not,
and
those
are
things
to
be
discovered
and
then
there's
invariance
of
of
the
ones
that
we
might
discover,
there's
the
ones
that
anybody
cares
about
and
then
of
those
there's,
the
ones
that
we
care
to
adopt
as
normative
statements
in
a
future
version
of
the
spec.
F
Yeah,
I
I
I
think
I
think,
there's
a
yeah
there's
an
important
distinction.
You're
capturing
there,
which
is
just
basically
the
difference
between
discovered
in
variance
and
it's
called
aspirational
invariants,
which
is
there's
something
which
we
discover
to
be
true
about
the
spec.
And
then
the
question
is:
do
we
want
to
formally
declare
that
this
truth
thing
should
always
be
true?
F
And
then
there
are
other
things
which
are
oftentimes.
Things
which
are
are
are
mostly
true
and
and
and
then
the
question
is,
you
know:
should
we
modify
the
spec
to
actually
make
them
true?
F
And
there
is
a
you
know
where
this
comes
up
is
is
when
somebody
makes
a
proposal
which,
which
would
violate
one
of
either
one
of
these
kinds
of
either
aspirational
or
discovered
invariants,
and
somebody
raises
the
the
objection
of
well
then,
if
you
do
that,
it's
going
to
violate
the
following
invariant
and
then
we
have
a
discussion
of
whether
that
invariant
is
actually
real
or
not.
A
Would
it
be
helpful
to
propose
terms
some
for
this
taxonomy?
I
I
I
would
suggest
that
what
what
what
chip
is
describing
as
a
discovered
invariant
might
be.
Maybe
the
term
precedent
would
be
useful
to
capture
that
idea.
A
It
is
okay,
the
perhaps
we
should
just
take
that
and
take
note
and
proceed
all
right.
A
That
there
might
be
an
opportunity
to
to
to
clarify
on
side
to
some
terminology,
we
don't
know
we
haven't
decided
or
okay.
We
don't
have
a
proposal
yet
for
what
those
terms
should.
A
D
C
Okay,
so
the
first
bullet
point
here
is
is
really
relates
to
the
the
earlier
point.
I
was
making
that
we're
calling
that
we
might
be
calling
precedent.
D
F
Well,
in
fact,
in
fact,
actually
go
back
and
go
back
to
that
that
actually
touches
on
an
important
question.
That
was
a
little
bit
controversial
when
this
whole
thing
arose
in
the
in
the
plan
area.
Last
time,
which
is
wanting
to
write
down
things
in
the
spec
that
have
the
flavor
of
you
know,
the
following
things,
which
are
not
true,
shall
never
be
true,
which
is
to
say,
you
almost
might
call
them
design
principles
that
we
make
normative,
and
currently
the
spec
has
few
of
any
of
these.
F
Somebody
actually,
I
think,
I
think
you
skipped
back
two
slides.
No,
no
back
back
one.
F
Yes,
yes,
the
the
the
the
question
about
when
a
specific
committee
member
is
not
present
is,
I
think,
a
big
big
deal
part
of
this,
which
is
having
to
ensure
that
there's
always
somebody
present
to
to
to
ensure
that
a
particular
stupid
thing
gets
flagged.
If
somebody
tries
to
propose
it,
you
know
the
the
that
it
puts
a
duty
of
vigilance
on
particular
individuals
to
compare
about
care
about
particular
things
as
opposed
to
having
whatever
the
principle
that
they're
being
vigilant
about
being
written
into.
This
fact.
F
A
Yeah
any
protected
property
of
the
specification.
F
F
F
I
I
think
I
understand
what
let
me
see
if
I
can
come
up
with
a
plausible
interpretation
of
what
you
might
mean
here.
The
the
question
is:
there's
there's
sort
of
the
the
description
of
what
the
invariant
you
know
is,
but
then
there's
also.
Why
is
it
there
sort
of
the
difference
between
the
letter
of
the
law
and
the
spirit
of
the
law,
whereas
you
could
have
something
which
complies
with
the
the
letter
of
law
but
violates
the
spirit
of
it.
C
So
so
what
does
validity
mean.
F
Well,
when
somebody
raises
the
question
of,
should
we
even
have
that
invariant?
Is
that
a
valid
thing
for
us
to
be
legislating
in
the
spec,
going
back
to
the
reason
why
we
put
it
in
there
forms
part
of
the
argument
as
to
why
it
should
be
there.
H
So
we
do
have
a
precedent
here
somewhat
recently
with
hashbang
the
claim
was.
The
spec
holds
a
current
invariant
before
hashbang
that
you
can
append
comments
to
the
top
of
any
file
without
effect
after
hashbang.
That
is
no
longer
true,
and
the
thing
here
was
we
were
questioning
the
validity
of
such
an
invariant.
C
Okay,
so
the
reason
why
the
word
validity
confuses
me
is
that
before
hashbang
was
added,
but
after
we
decided
that
we
are
allowed
to
add
it,
we
I
it
the
you
know
this
property
did
not
stop
being
true
of
the
spec,
it
just
stopped
being
it
stopped
being
permanent.
It
stopped
being,
I
suppose,
an
adopted
invariant
in
the
the
way
that
you'll
use
putting
things,
but
it
was.
It
still
happened
to
be
true
of
the
spec.
H
Correct,
I
do
not
believe
the
validity
is
about
the
actual
implementation
of
an
invariant
or
if
the
spec
adheres
to
an
invariant.
Currently,
I
believe
the
rationale
is
what
we're
talking
about
here
and
if
the
invariant
was
intentional,
if
the
intent
of
the
invariant
needs
to
be
considered
something
normat.
A
So
look
perhaps
you
know-
or
perhaps
we
can
get
around
the
word
validity,
because
I
think
that
th
this
this
this
sentence
could
be
equally.
The
spirit
of
the
sentence
could
be
equally
valid
or
invalid,
expressed
without
without
the
word
validity.
A
The
rationale
is
an
argument
to
revisit
if
the
invariant
is
questioned
in
a
for
or
contested
for
the
purposes
of
a
modification
to
the
language
in
the
future.
Okay,.
C
A
D
C
Yeah,
I
think
I
don't
understand
why
I
mean
just
in
the
example,
for
example.
So
the
thing
about
cannot
be
captured
by
the
specification
text
alone.
When
I
read
that,
I
think
I
need
an
example
and
then
the
example
is
module
resolution
graph
order
and
why
it
cannot
be
changed.
Is
that
not
written
down
in
the
spec
and
is
there
a
reason
for
it
not
to
be
written
down
in
this
world.
F
F
Okay
and
maybe
maybe
the
the
the
the
the
actually
taken
responses.
Well,
then
they
should
be,
but
in
fact
I
think
there
are
things
which
are
kind
of
the
sort
of
penumbra
of
the
specification
to
use
an
overused
legal
word
which
are
which
are
kind
of
rules
that
everybody
knows
and
follows
that
aren't
written
down
that
go
back
to.
For
example,
the
discussion
in
the
committee.
H
So,
yes,
we
had
a
discussion
about
module
evaluation
order
and,
in
particular,
node
was
asking
about
evaluating
modules
in
a
different
manner
than
the
specification
requires
them
to
be,
because
the
specification
does
not
limit
hosts
to
do
something
called
hoisting,
where
we
could
take
a
leaf
node
within
a
module
graph
and
hoist
it
as
if
there
was
an
import
before
the
entire
module
graph.
H
That
simply
cannot
be
put
in
the
specification.
In
fact,
it
comes
down
so
far
that
even
within
the
spec
itself,
module
ordering
is
not
100
assured
for
parallel
graphs
because
of
dynamic
import.
H
G
H
H
G
G
H
G
D
G
Right
yeah
because
it
was
not
specified
because
it
was
left
up
to
implementation,
and,
and
so,
if
you
were
to
in
impose
it
now,
that
would
be.
That
would
require
changes
in
implementations.
H
It
would
break
just
the
fact
that
you
can
have
things
run
in
parallel.
It
is
an
incredible
slowdown
to
esm,
which
is
already
slow.
H
Also
get
into
things
like
top-level
await
now
has
parallelism
within
its
siblings,
and
so
even
if
we
do
for
serialization
you're
now
trying
to
order
the
graph
based
upon
awaits
within
the
graph,
which
is
I
don't
understand,
how
we'll
do
that.
C
When
you
say
parallelism,
I'm
I'm
confused.
You
mean
non-determinacy,
because
it's
still
the
case
that
each
event
executes
to
completion
on
each
turn
executes
the
completion,
with
a
full,
sequential
order
of
turns
it's
just
that
the
turns
with
the
top
level
await
siblings,
that
what
that
full
serialization
is
is
not
a
deterministic
consequence
of
the
spec.
Is
that
what
you
mean.
G
A
A
C
Yeah
yeah
and
I
think
the
precedent
concept
that
she
likes
writes
down.
There
is
very
interesting,
and
some
other
examples
of
things
that
we
believe
in,
but
can't
write
down,
would
be
very
interesting
to
have.
A
Yeah
perhaps
it
would
be
useful
to
coin
a
term
of
an
emergent
invariant.
H
So
mark
I
understand
what
you're
asking
there
is
some
parallelism
with
certain
pr's
in
node,
where
we
are
doing
stuff
in
the
background
for
our
loader.
If
you
are
talking
about
just
doing
things,
sequentially
as
ticks,
that
is
still
preserved,
but
the
ordering
of
the
ticks
is
not
guaranteed
due
to
things
like
io.
H
Yes,
so
we
have
designs
for
instrumenting
the
es
modules
and
common
js
modules.
In
the
same
way,
we
use
effectively
atomics
dot
weight
to
block
common
js
modules,
while
our
loader
does
asynchronous
operations
on
a
different
thread.
C
Okay,
let's
take
this
offline
because
I
think
this
is
because
I
think
we're
we're
very
far
afield
from
yo-yo's
talk
on
this
one.
But
I
I
I'm
confused
that.
I
do
want
to
understand
this
and
maybe
actually
just
point
to
a
future
meeting,
because
this
group
should
understand
that
probably.
D
C
I
think
I
think
this
question
is
definitely
the
question
question
that
needs
to
be
asked.
I
think
this
slide
asks
it
well.
I
certainly
hope
that
invariants
are
more
like
need
consensus,
prs
than
likeful
proposals.
Okay,.
A
D
Actually,
I
do
have
another
point
I
might
want
to
suggest.
I
just
realized
this,
but
I'm
wondering
if
ecma
or
the
other
tc
working
groups
related
to
javascript
ecmascript.
C
As
far
as
I
know
not,
I
mean
other
people
that
expert
who
explore
the
concept
that
are
not
normally
part
of
the
group.
I
joined
us
for
this
for
that
discussion
and.
C
A
good
question,
so
tc53
will
certainly
be
interested
in
this.
The
because
they're
trying
to
then
be
not
trying
to
they
are
standardizing
on
cess
as
the
base
javascript
for
their
work,
but
cess
will
write
down
lots
of
invariants
that
are
not
invariant
for
javascript
as
a
whole,
but
nevertheless,
the
more
such
invariants
are
written
down
for
javascript
as
a
whole.
The
better
off
the
tc53
effort
will
be,
but
but
yeah
the
the
differentiating
factor
there
is
that
their
their
their
base
standard
is
ces,
not
normal.
Javascript.
C
D
Okay,
the
main
point
I
was
trying
to
make
is
that
there
we
should
there
should
be
some
collusion,
I
suppose,
or
coordination
between
the
two
working
groups
in
terms
of
how
invariants
like
this
are
handled,
and
what
I'm
trying
to
what
I'm
trying
to
suggest
is
it'd
be
nice
to
avoid
having
one
group
of
rule,
one
set
of
rules
for
tc39
and
another
for
tc53.
That's
what
I'm
trying
to
get
at.
C
Okay,
yeah,
I
don't
I
the
important
pla.
C
A
All
right,
let's,
let's
go
over
it
again
from
the
top
and
see
if
thoughts
from
the
bottom
percolate
upward.
Let's
see.
A
Yeah,
oh
boy,
buggy.
I
think
that
I
think
that
the
meaning
is
internally.
A
Is
this
is
insightful?
I
didn't.
I
didn't
catch
this
the
first
time
through
properties
that
cannot
be
written
down.
A
Yep
and
apart
from
validity,
we
were
great
with
this
one.
C
H
We're
stating
here
that
should
has
a
white
list
of
cases
where
it
can
be
broken
rather
than
stating
that
a
implementation
can
willfully
ignore.
Okay,
good.
A
Good,
so
these
are
more
like
these
are
more
like
normative
exceptions,
yeah
less
and
not
advice.
C
Right
right,
you're,
correct
it's
completely
different
than
the
rfc.
I
was
not
seeing
that
and
yeah
it's
an
example
would
be
no
hidden
primordial
state
except
for
date.now
math.random
right
I
mean
it's
also,
it's
almost
no
hidden
primordial
state
and
the
exceptions
are
explicitly
called
out.
D
A
And
we
could
borrow
the
ambiguity.
The
chip
pointed
out
earlier
near
misses.
G
G
Oh,
I
think
that
it
actually
is
conforming
with
the
rfc
language,
because
it
is
relating
to
invariants.
Invariants
are
properties
of
the
specification
in
this
context,
not
of
implementations.
So
a
proposal
should
not
violate.
D
G
C
Okay
and
then
the
additional
requirement
that
the
exceptions
themselves
are
written
down
explicitly
neither
follows
from
the
rfc
should,
but
also
it
does
not
violate
the
rfc
sure.
Is
that
your
right?
It's.
A
Okay,
that
sounds
good
to
me.
Does
anybody
have
any
further
thoughts
before
I
stop
the
screen.
A
Share
all
right
leo:
do
you
still
have
is
leo
still
on
the
call
leo
is
not
still
on
the
call
okay.
Well
then,
that
that's
that's!
That's
our
run
of
topics
for
this
week.