►
From YouTube: SES Meeting: Hidden Intrinsics and Petrification
Description
We discuss mechanisms for enumerating hidden intrinsics and the “petrification” of object graphs.
B
But
it's
not
obvious
in
in
the
spec.
There
is
a
few
other
objects
like
this
usually
records,
and
things
like
that
and
they're
usually
marked
as
being.
This
is
only
a
spec
object.
It's
never
exposed
to
user
code
that
one
actually
is
not
specifically
marked
as
is,
but
even
then,
if
it
was,
it
would
be
in
some
weird
section
and
then
that
the
iterator
itself
instance
is
propagated
inside
a
record
all
throughout
a
bunch
of
places
in
the
spec.
B
B
The
reason
this
came
up
is
someone
realized
that
the
iterator
helpers
actually
has
proposed
currently
do
expose
that
object
in
one
very
specific
circumstance
when
you
do
async
iterator
dot
from
and
you
pass
a
sync
iterator,
it
will
actually
return
that
that
wrapped
iterator
and
does
allow
the
discover
all
the
ability
of
the
prototype.
I'm
sorry.
B
B
B
The
iterator
developers
that
proposal
has
other
hidden
intrinsics,
so
when
you
call
any
of
the
iterator
helpers
and
you
so
if
you
do
async
iterator
dot
from
of
a
async
iterator,
it
doesn't
well,
I
think
it
returns.
I
think
it
wraps.
So
under
certain
certain
circumstances,
they
return
the
iterator
right
away.
B
Under
other
circumstances,
it
returns
a
reputator,
so
there
is
a
wrapped,
a
territory
helper,
something
prototype
in
those
in
that
in
that
proposal
as
well
and
it's
another
place
that
has
a
intrinsic
that
you
cannot
reach
through
walking
the
global.
I
heard
that
regex
metro
has
a
thing
similar
to
that.
I
actually
need
to
double
check
that,
so
it
actually
happens
quite
a
bit
with
iterators
that
those
prototypes
are
not
discoverable
by
syntax.
B
D
B
C
D
Yeah
I
there
was
a
remember
that
rom
had
that
api,
where
you
can
get
the
intrinsics
in
the
past.
We
remove
it
in
favor
of
having
a
more
explicit
api
that
doesn't
require
rounds,
so
you
can
get
in
transects.
I
I'm
more
surprised
about
one
of
the
pieces
that
you
mentioned
that
up,
even
today,
there
are
intrinsics
listed
in
in
the
table
that
are
not
reachable
by
by
user
line
code.
Is
that
what
you're
saying
that's
it?
Yeah.
C
B
Yeah,
so
what
I
would
like
to
bring
about
gg3
is
this
problem
of
so
I
the
concern,
though,
is
that
the
this
problem
really
exists
in
systems
like
hardened
javascript,
I'm
not
even
sure
if
the,
if
realms
and
membranes,
build
around
realms
care
about
that
too
much.
That's
where
you
come
in
karate,
I
I
don't
know
if
it's
yeah.
D
So
all
these
all
these
things
will
probably
belong
to
one
realm
only
and
then
in
the
new
realm
that
we
create
a
new
shot
around.
We
just
ignore
most
of
them
and
only
a
handful
of
men
are
really
use
by
by
the
code
running
in
that
realm.
So
I
I
will.
I
would
not
expect
this
to
affect
me
a
membrane
but
a
membrane.
D
If
you
want
to
do
something
special
about
those
those
type
of
objects
you
you
need
to
have
access
to
to
to
those
intrinsics
up
front
to
do
any
kind
of
remapping.
Like
imagine
that
you
want
to
be
able
to
remap
one
of
you
from
one
side,
one
async
iterator
from
one
side
to
the
asynchronous
or
the
other
side
in
some
sort
of
form.
You
would
need
to
have
access
to
that,
but
I
don't
I
don't.
I
don't
foresee
a
problem
with
the
membranes
yeah.
B
So
it's
it's
mostly
a
problem
for
for
hardened
javascript,
where
we
want
to
freeze
any.
I
mean
I
guess
it
is
a
problem
in
in
general,
because
it's
it's
somewhere
where
something
could
get
modified.
That's
a
that's!
A
problem
like
something
could
go
in,
modify
the
prototype
and
then
the
prototype
functions
are
called
by
by
a
by
for
off
and
by
syntax
and
all
sudden,
like
you,
somebody
could
have
subverted
the
way
those
operations
work.
D
C
C
B
Yeah,
so
I
guess
an
attack
in
this
would
be
some
code
that
would
reach
into
that
prototype,
because
it
knows
how
to
do
that.
Modify
the
next
prototype
method
to
do
something
funky
with
it,
intercept
the
results
or
whatever
and
then
now
every
time,
any
other
code
that
isn't
aware
of
it.
Iterates
with
the
four
weight
in
the
sync
iterator
would
have
its
results
of
that
iteration
altered,
okay
or
observable.
C
Okay,
so
so
so,
let's
just
so
there's
three
category,
we
can
talk
about
three
categories
of
intrinsic
there's,
reachable
by
name
reachable
by
api
and
reachable
by
syntax.
That
was
pretty
much
already
stated.
The
category
that
the
the
the
particular
ones
that
are
the
new
concern
here
are
reachable
by
api
and
the
question.
C
B
C
C
D
Got
it
okay,
one
one
small
detail
is
like
to
make
it
even
worse,
even
in
order
to
get
access
to
one
of
these
objects
that
you
have
to
call
an
api
to
get
your
hands
on.
Then,
if
that
api
is
a
sync,
then
you
have
to
wait
for
the
next
one
to
get
your
hands
on
that
object
and
then
get
the
intrinsic
out
of
it.
That
makes
it.
B
E
C
C
We
need
a
a
a
an
algorithmic
way
of
being
sure
to
reach
them
all,
for
example,
for
hardened
javascript,
for
a
hardened
javascript
shin
for
a
purpose
of
freezing
them.
Obviously,
hardened
javascript
becoming
a
proposal
will
no
longer
need
a
shim
at
some
point,
but
the
shim
is
is
a
nice
diagnostic
criteria.
B
E
B
B
B
A
F
The
mark-
and
I
were
talking
at
the
beginning
before
recording,
started
about
discussion
in
tc39
github
that
started
from
array:
immutable,
arrays,
let's,
let's,
let's
keep
it
to
that
and
the
question
in
that
discussion
we
covered
the
the
idea
of
a
of
another
integrity
level
on
top
of
sealed
and
frozen
came
up
model
uses
the
word
petrify
for
this,
so
I
will.
I
will
use
that
just
just
to
have
a
label
for
it.
F
Just
like
freeze
is
non-recursive
and
harden
brings
recursive
rules
to
that,
and
secondarily
that
not
every
object
could
have
this
new
integrity
level
applied
to
it,
because
it
would
effectively
render
them
useless
for
their
for
their
given
purpose.
The
examples
more
excited
for
that
are
promises
and
weak
maps
and
sets.
F
Sorry
and
proxies-
and
I
thought
that
discussion
was
helpful,
because
moddable
would
very
much
like
to
see
a
general
purpose,
integrity
level,
that
that
allows
more
objects
to
be
fully
immutable
in
the
language,
and
this
this
seems
to
give
us
an
opening
to
work
on
that.
That
has
has
at
least
some
some
consensus
around
it
from
the
early
discussion
and
then,
as
mark
pointed
out
in
the
discussion
earlier,
that
would
give
us
having
a
shallow
version
of
petrify
would
give
us
a
path
to
a
recursive
version
of
it
down.
C
Over
here
so
yeah,
so
also
the
the
other
thing
that
would
need
to
not
be
included
because
to
include
it
would
be
an
attack.
The
first
approximation
of
it
was
the
private
fields
of
instances
of
classes,
and
then
you
know
we
all,
and
then
we
all
had
the
sense
that
it
would
be
nice
for
the
class
itself
to
be
able
to
to
cause
those
private
fields
to
be
frozen.
C
So
then,
matthew
brought
up
the
idea
that
maybe
there's
some
means
a
private
symbol
or
something
some
means
by
which
the
the
class
code
itself
could
opt
in.
So
so,
without
trying
to
be
too
specific
there.
Let
me
say
that
yeah.
I
support
the
idea
that
a
class
should
somehow
be
able
to
do
that,
whether
it's
an
extension
of
the
same
mechanism
or
distinct
mechanism
and
how
it
opts
in,
I
think
we
can.
C
You
know
I
can
put
let's
postpone
that
until
we
get
the
rest
of
this
straightened
out
the
so
so
what
I
was
suggesting
was
that
the
that
we
take
the
the
concept
of
harden
as
long
as
we're
introducing
this
hardened
thing,
which
is
this
transitive
version
of
something
right.
Now,
it's
a
transitive
application
freeze.
C
We
could
make
the
the
single
step
version
the
shallow
thing
something
stronger
than
freeze
and
exactly
this,
the
way
that
peter's
describing,
but
that
would
but
then
we
should.
You
know
the
hardened
that
we're
proposing,
which
is
the
transitor
aversion,
should
just
be
a
transitor
version
of
whatever
the
shallow
thing
is
so
so
I
was
just
as
to
have
a
name
for
it.
C
I
was
just
calling
it
hardened
step
is
the
is
each
atomic
step
of
harden
would
be
a
hardened
step,
and
then,
if
we
make
that
a
new
integrity
level,
then
we
could,
we
might
also
be
able
to
bundle
in
with
that
that
any
property
that
gets
frozen,
that
is,
that
is
non-writable
on
an
object
of
that
integrity.
Level
itself
does
not
cause
the
override
mistake.
In
other
words,
it
is
possible
to
override
that
non-writable
property
in
an
object
that
inherits
from
the
hardened
stepped
object.
C
I
think
that
that
it
will
be
on.
It
will
be
difficult
to
untangle
that
from
the
issue
of
enabling
attack
and
then
finally,
there's
the
the
the
third
api
service,
which
is
the
predicate
or
the
the
the
predicate
that
doesn't
look
like
a
predicate
to
ask,
is
pure
or
what
are
all
of
the
paths
by
which
this
thing
is
not
pure
or
something
like
that.
B
C
B
B
I'm
somewhat
concerned
about
making.
I
don't
understand
why
we
need
to
make
this
shallow
operation.
That
harden
does
stronger
than
freeze,
and
maybe
that
that's
because
I
I
still
have
a
difference
of
opinion
on
what
that
operation
should
do,
and
I
don't
know
how
we
want
to
call
it
if
it's
since
we
can't
use
petrify
make
immutable
if
you,
if
you
wish
or
make
make
mutable
on
surface,
because
it's
shadow.
B
B
E
C
Therefore,
if
you
haven't
opted
in
is
what
happens
by
default?
Is
that
it
gets
rejected
and
then
having
having
made
that
distinction.
We
can
then
enumerate
the
built-ins
that
we
want
to
protect
from
this
operation
versus
that
we
want
to
be
affected
by
this
operation
and
say
that
the
built-ins
that
are
affected
by
this
operation
are
retroactively
rationalized
as
built-ins
that
have
opted
in
to
be
affected
and
that
the
encapsulating
primitives,
like
promise,
weak
map
and
proxy
are
are,
are
the
ones
that
have
not
opted
in
the
ones
like
array,
buffer,
typed
array
date,
etc.
B
C
B
My
concern
is
still
with
the
point.
I
stated
how,
if
so,
for,
for
the
example
of
proxy
and
if
you
try
to
freeze
a
proxy
and
so
on,
there
are
invariants
that
the
engine
can
check
once
that
has
been
done.
It's
basically
a
similar
case
where
you
ask
a
proxy
to
freeze,
and
then
you
check
that
proxy
has
actually
frozen.
E
E
C
I
think
very
much.
The
goal
is
that
things
which
are
built-ins
built-in
concepts
that
are
used
as
encapsulation
boundaries
are
not
threatened
by
this
and
closures
and
class
instances
and
weak
maps
are
all
encapsulation
bands
they're
all
used
for
purpose
of
encapsulation
boundaries
and
therefore,
in
this,
retroactive
rationalization
would
have
to
be
considered
primitives
that
have
not
opted
in.
B
Right
but
okay,
so
let
me
let
me
clarify,
then,
if
I
have
an
object
that
is
built
as
a
closure
or
an
object,
that
is
in
a
class
instance
that
doesn't
use
private
fields
but
instead
uses
a
weak
map,
and
I
claim
I
implement
the
protocol
to
say
I
will
accept
getting
frozen,
and
I
don't
because
how?
How
can
the
engine
enforce
that
the
immutable
data
that
I
would
store
in
closure
or
in
weak
map
is
not
modified?.
C
C
So
a
a
shallow
make
immutable,
a
proxy
would
already
qualify
and
that's
obviously
vacuous
likewise
with
a
weak
map.
The
the
the
internal
slot
is
a
pointer
to
an
internal
data
structure,
the
slot
you
know
which
data
structure
the
slot
points
to
doesn't
get
modified,
so
the
shallow
version
of
make
immutable
interpreted
literally
as
applied
to
a
weak
map,
is
again
vacuous.
C
So
I
think
I
think
that
that
when
we
say
that
these
things
are
are
not
opting
in
or
you
know
when
we
say
what
it
would
be,
that
would
be
made
immutable
if
this
operation
succeeded
such
that
it's
meaningful
in
the
recursive
case,
I
think
we
need
to
dive
to
some
degree
into
the
semantics
that
we're
attributing
to
these
things.
The
deep
case
is
the
only
case.
C
I
think
that
gives
us
a
good
semantic
footing,
because
either
the
thing
the
either
the
pointer
to
the
to
the
root
object
of
the
subgraph
is
pure
or
it
is
not.
Either
there
is
mutable
state
transitively,
reachable
or
there
is
not,
and
even
that
has
a
definitional
problem
around
private
fields
of
classes,
because
private
fields
of
classes
are
given
a
semantics
using
the
weak
map
model.
The
weak
map
would
be
a
mutable
weak
map
that
is
part
of
the
class,
so
a
class
defining
private
fields
would,
without
special
arrangement,
have
to
be
considered
un.
B
B
C
B
I'm
skeptical,
you
can
specify
it
cleanly
because
there
are
all
those
cases
where
something
might
actually
be
immutable,
but
it's
not
obvious.
It
might
be
immutable
in
practice,
but
it
really
isn't.
No,
it
might
be
sorry,
it
might
be
immutable
in
practice,
but
it
doesn't
appear
like
it
is.
You
mentioned
one
case
of
that
and
then
I
am
fairly
confident.
No
engine
will
actually
well
maybe,
except
for
xs,
want
to
implement
this.
B
I
am
I
I
think
the
we're
more
confident
is
that
we
might
be
able
to
like
have
a
boundary
that
says.
Like
you
run,
you
call
this
method
in
a
non-mutable
way
like
I
don't
want
any
side
effects
when
I
call
this
and
there
is
a
shortcut
throw
that
happens.
If
any
immutable
operation
actually
happens
during
that
medal,
called
method
call.
B
C
So
you
might
be
right
about
what
engines
are
willing
to
implement
on
the
specification
thing.
I
don't
see
a
problem
specifying
something
cleanly
and
I
don't
even
see
a
problem
specifying
something
that
I
expect
xs
would
be
willing
to
implement,
and
that
gives
us
a
place
to
stand
where
we
can
start
experimenting
with
it
and
start
to
start
talking
to
the
other
engines
about
what
they
would
be
willing
to
implement.
C
If
the
operation
completes
you
know
under
this
restriction,
then
you
know
that
it
didn't
modify
any
pre-existing
state
and
and
that's
a
little
tricky
to
define
because
well,
first
of
all,
there's
the
issue
about
for
private
fields.
Where
is
the
mutable
state,
and
I
think
that,
given
return
override,
the
mutable
state
has
to
be
attributed
to
the
class,
not
the
instances.
B
E
B
C
Once
again,
it's
not
impossible.
It's
I
expect
we
can
specify
it.
I
expect
xs
will
be
willing
to
implement.
It
largely
already
has
implemented
it.
If
I
understand-
and
that
gives
us
a
place
to
stand
to
experiment
with
it-
and
you
might
very
well
be
right-
that
it's
impossible
to
get
the
other
engines
to
agree,
but
that's
a
different
level
of
impossible
is.