►
From YouTube: SES Meeting: Promise brand check
Description
Wherein we discuss reentrancy hazards of Promise.resolve(x) that motivate the need for a promise brand check, the hazards of a Promise brand check, and how to mitigate them.
A
Welcome
to
the
assess
meeting
today
is
may
11th
of
2022,
and
we
have
added
a
topic
to
the
agenda
of
discussing
how
to
determine
whether
a
promise
is
a
native
promise
without
consulting
its
api.
A
Even
if
accidentally,
this
is
something
that
matthew
brought
up.
I
believe
as
an
issue
on
tc39
and
has
had
quite
a
bit
of
discussion
in
matrix
over
the
last
couple
of
days
or
day,
and
so
we're
going
to
start
with
that
and
then
there's
a
follow-up
topic
about
that.
Matthew
brings
up
and
hopes
to
discuss
with
charity,
provided
that
provided
that
turns
out
to
be
a
good
topic
for
today
regarding
errors
thrown
from
shadow
realms.
A
So
let's
kick
it
off
with
the
let's
title:
the
topic
promises
promise,
which
I
realize
is
a
mistake,
because
it's
a
framing
a
question
in
certain
terms
of
its
answer,
but
before
we
started
talking
mark
raised
the
issue
of.
Why
is
promise
resolve
not
satisfactory.
B
Should
I
go,
I
mean,
I
think
I
think
the
problem
is
that
promise
resolve
is
not
satisfactory.
The
reason
is
promise
resolve,
doesn't
does
a
lot
of
things
and
when
it
finds
the
first
thing
it
does
is
actually
a
brand
check
for
a
promise
and
if
it
finds
a
promise,
it
goes
on
and
does
a
couple
things.
It
checks
for
the
constructor
property
of
the
promise
and
it
also
checks
the
it
also
does
a
get
of
the
then
of
that
promise
object.
B
Those
two
things
can
be
controlled
by
user
code.
That
means
calling
promise
resolve
x,
may
trigger
code
controlled
by
the
user
and,
in
effect,
cause
synchronous
execution
which
may
end
up
in
some
re-entrancing.
If
so,
if
you
want
to
guard
against.
B
B
The
getter
for
then
and
the
getter
for
constructor.
A
A
With
anything
like
this,
which
is
similar
to
array
radius
array,.
C
C
B
It
fails,
but
if
it
succeeds,
it
goes
on
to
synchronously,
do
a
species
check
and
a
and
and
grab
the
the
bend
function.
So
if
you
have
a
native
promise
that
has.
B
C
B
B
Awaits
I
need
to
look
again:
a
weight
was
patched
to
a
fast
track.
I
think
it
does
a
check
of
the
then
and
fast
fast
there's
a
fast
path.
If
it's
the
original
one.
C
B
Oh,
oh,
but
no
matter
what
boat
then
doesn't
do
dot
then
also.
Does
a
species
check
with
a
dot
constructor,
no
matter
what.
C
Oh,
I
see
okay.
B
So
the
only
safe
way
to
handle
this
case
is
to
do
promise.
Dot,
resolve
nothing
dot
then,
and
then
return
have
a
thunk
that
returns
the
the
possibly
venable
and
the
only
case
where
it's
safe
to
do
promise
don't
resolve
x
is
if
x,
is
not
an
object.
Anything
else.
You
risk
triggering
a
trap
on
on
the
object,
because
at
that
point
it
might
be.
It
might
also
be
a
proxy.
So.
C
Okay,
so
I
need
to
really
we
need
to.
We
should
take
a
look
at
the
spec
on
promise
resolve,
because
this
is,
it
sounds
like
promise.
Resolve
desperately
needs
to
be
fixed
independent
of
whether
we
have
a
promises,
promise
or
not.
B
Okay,
so
it
does
is
promise
which
is
a
brand
check,
and
then
it
gets
the
constructor
if
it's
the
same
constructor
f
as
what
promise
resolve
is
attached
onto
it
just
returns
the
the
promise,
as
is.
C
B
Promise
resolve
if
it's
a
promise,
does
a
constructor
brand
check,
synchronously.
B
And
then
the
resolve
functions
once
you
adopt
a
promise.
Where
is
this
again.
B
Where
is
this
being
called?
This
is
where
there
we
go
okay,
so
the
resolve
functions
will
end
up,
so
this
might
end
up
being
called
synchronously
as
well
during
it
then,
and
it
basically
does
it
gets
of
the
den.
B
So
whenever
you
call,
whenever
you
call
a
resolve
at
the
place
where
you
call
results
so,
for
example,
you
have
a
new
promise
and
you
get
the
executor
you
get
the
result
from
that.
You
call
anywhere
resolved
during
your.
B
Your
executor
block
synchronously,
once
you
call
when,
where
you
call
resolved
the
thing
you
call
resolve
on.
If
it's
an
object,
we
will
do
a
get.
Then.
B
That
is,
if
you
resolve
through
any
objects.
C
B
So
there
is,
there
is,
basically
it
will
trigger
the
code
as
well.
There
synchronously.
B
This
is
only
really
a
problem
of
synchronous
if
you
create
the
only
way,
this
is
really
visible
to
user
code
is,
if
you
create
a
promise
using
new
promise
and
and
extract
its
result,
function.
B
Promise
result
functions
is
the
it's
literally
the
result
of
of
the
the
promise
constructor.
C
B
But
it
it
is
internally
used
also,
for
example,
at
the
end
of
it
then,
to
to
resolve
the
the
current
promise
with.
So
if
you
return,
if
you
return
a
value
from
a
den
block,
this
is
what
will
be
called
to
resolve
the
current
promise
that
was
going
to
be
created
by
then.
Okay.
C
B
B
Promise
resolve
it
will
call
it
create
a
new
previous
capability
and
then
create
resolve
with
whatever
value
was
given
synchronously.
A
B
C
C
So,
let's
go
back
to
one
of
the
questions
that
I
think
was
not
on
one
of
these
calls,
but
it
was
internal
to
agora
or
it
was
on
the
internal
chat,
so
agor.
So
our
library,
you
know
endo,
has
an
e
dot
when
and
e
dot
when
is
as
well
as
the
just
invoking
through
e
but
e
dot.
When
is
supposed
to
do
a
full
protection
from
synchronous
re-entrances.
B
B
Without
there
is
no
way
to
do
a
branch
check
on
a
promise
that
doesn't
trigger
anything
else.
So
if
you
look
at
the
spec
anywhere,
where
is
promise
it?
It's
there's
only
two
places
where
his
promises
use.
The
brand
check
promise
resolve,
which
we
define
triggers
a
constrictor
trap
and
promise,
then,
which
also
does
a
constructor.
C
Trap,
okay,
so
I
suppose
well,
this
really
sucks
which,
as
I
suppose
the
point.
B
Yeah,
which
is
why
I
was
trying
to
see
if
we
could
have
a
clean
brand
check
in
the
spec
with
so
that
we
wouldn't
have
to
incur
a
hit
for
for
native
promises.
B
Right
now,
if
you
find
an
object,
you
you
can
get
away
with
with
a
primitive
and
doing
a
promised
result
of
the
primitive.
But
if
you've
got
an
object,
you
don't
know
what
that
will
do
so.
C
Yeah
yeah,
okay,
so
so
I
think
promise
dot
is
promise.
It
has
a
strong
case
for
it
from
what
you
said.
I
accept
that.
B
The
pushback
we're
getting
right
now
and
promise
that
his
promise
is
that
most
people
don't
care
about
that.
What
they
should
care
about
is
whether
something
is
attainable
or
not.
Eventually,
and
it's
right
for
abuse
of
people
potentially
do
conditional
awakes,
which
is
an
anti-pattern
and
so
basically
having
anything
that
lets.
People
think
they
can
conditionally
await
a
value.
B
Is
a
very
good
objective.
I
actually
would
counter
that,
though,
because
all
of
this
all
of
this
stems
from
promises,
a
plus,
which
is
very
explicit
about
the
the
then
property
being
retrieved
only
once
so,
just
checking
it
checking
if
something
is
thenable
not
even
promise
requires
holding
on
to
the
then
method
and
then
that
being
the
thing
that
you
invoke
right
so.
C
B
Any
prior
test
that
reads
the
then
has
already
invalidated
from
a
promises,
a
plus
perspective
use
of
the
object
as
available
yeah,
but
that
an
argument
could
be
made
that
one
test
is
done
by
user
code
and
the
other
one
is
done
by
the
engine
and
the
engine
can't
really
be
responsible
for
brand
checks
that
the
user
code
does.
C
Let's
try
to
separate
reasons
why
one
would
care
what
promise
a
plus
says.
C
You
know
one
one,
the
the
two
that
I
can
think
of
without
having
seen
you
know
this.
This
online
argument,
the
two
that
I
can
think
of
are
that
promise
a
plus
specified
something
a
particular
way
for
a
good
reason
and
before
changing
our
minds
on
that,
we
should
understand
the
reason
and
at
least
change
our
minds
in
an
informed
manner,
and
it
sounds
like
this
fection
then
once
might
be
one
of
those.
C
C
So
if
something
has
to
change
to
bring
things
back
into
alignment
it
it's
got
to
be
a
plus
that
changes
so
is
it
is.
Is
there
another
reason,
or
is
it
the
first
one
that
a
plus
did
the
did
something
for
a
good
reason,
and
we
should
respect
that?
No.
B
No,
a
plus
is
actually,
I
don't
believe
a
plus
says
anything
here,
but
this
not
not
for
the
testing,
but
the
it
specifies.
What
happens?
It's
basically
a
specification
of
the
then
method
more
than
anything
else,
and
it
they
they
do.
These
caching
reads
so
the
results
yeah.
B
Right
so
it's
actually
the
promised
adopted
state,
it
doesn't
say
how
you
adopted
the
state,
it
just
stays
adopted
state
and
then
so
technically
you
can
recognize
your
own
promise
in
any
way
that
doesn't
trigger
anything
and
just
adopt
it.
C
Right
and
there's
only
one
there's
only
one
way
that
doesn't
trigger
anything,
which
is
you
just
you
know
the
the
internal
state
that's
accessed,
you
know
directly
without
triggering
user
code.
Is
the
thing
that
you're
adopting.
So
it's
basic.
You
know
it's.
Basically,
there
is
no
interleaving
with
user
code
in
step.
2.3.2
here.
C
C
It
doesn't
say
that
okay,
so
so
the
three
the
three
points
underneath
again,
I
would
say
none
of
that
implies
interleaving
with
user
category.
B
Right
but
to
but
at
the
next
step,
where
it's
not
recognized
as
a
promise,
but
it
is,
you
know
an
object,
then
retrieve
then
test
it
if
it's
a
function
and
if
so
call
it
immediately.
C
B
The
delay
for
calling
then
was
only
fixed
in
committee.
Wasn't
fixing
promise
it
was.
C
B
And
it's
actually
technically
technically
promise
a
plus
native
promises
are
not
compliant
with
promise
a
plus
already
because
of
that,
and
that's
how
that's
what
actually,
what
triggered
the
whole
discussion
originally,
the
original
discussion
that
justin,
I
believe
brought
up
was
that
it
takes
too
many
takes
currently
for
adopting
a
native
promise,
and
the
solution
is
actually
to
do
a
proper
recording
of
your
own
promise
and
adopt
them
without
scheduling
a
dot.
Then,
at
the
later
turn.
B
B
Where
is
the
promise
result?
Functions.
B
Here,
cool
in
the
resolve
functions.
Currently
it
does
schedule
the
then,
even
if
you
recognize
it
as
a
native
I
mean
we
don't
it
doesn't.
C
B
So
it
doesn't
care
currently,
if
it's
a
native
promise
or
not,
and
the
direction
would
be
to
test
if
it's
a
native
promise
still
do
a
get
of
the
den
and
if
it
matches
the.
B
The
primordial,
then
it
would
bypass
the
scheduling
and
just
call
the
dot.
Then
the
internal
dot,
then,
because
we
know
the
dot,
then
of
the
spec,
doesn't
have
side
effects.
C
Could
you
go
to
the
the
the
spec
for
weight.
C
And
yeah
I
mean
it's
it's
all
together
I
find
it
I
mean
that's
what
it's
supposed
to
do.
I
would
have
been
horrified
if
it
did
not
call
promise
resolve,
but
now
that
we
understand
promise
resolve
the
my
surprise
is
that
weight.
B
Yeah
a
weight
also
synchronously
triggers
asynchronous
code
in
the
before
the
the
suspension.
B
It
doesn't
promise
result
just
returns
the
promise,
if
it's
a
native
promise.
B
A
So,
if
I'm,
if
I'm
not,
if
I'm
reading
this
correctly,
if
you
were
to
subclass
promise,
it
would
not
be
treated
as
a
native
promise,
it
would
be
treated
as
a
native
promise.
I'm
sorry
subclass
is
a
native
promise.
I
it
is,
but
it
doesn't
have
a
constructor.
That's
the
same
as
the
original
constructor.
It
doesn't.
B
Have
so
yeah
it
makes
it
into
a
base
promise
that
that
is
another.
That's
another
thing,
I'm
trying
to
figure
out
how
to
possibly
change,
but
let's
not
get
there
today,
yeah,
oh.
A
B
Started
so
there's
a
there
is
a
few
places
in
the
spec
that
forces
any
promised
subclass
into
a
base
promise.
But
wait
is
one
of
those
and
there's
a
wait,
and
there
is
also
the
async
from
sync
iterators
that
does
that
and
then
something
else.
Okay,.
C
So,
on
the
case
of
a
way,
without
you
don't
move
the
screen,
you
don't
want
to
be
looking
at
prom
all
right.
Okay,
the
so
await
calls
this
internal
promise
resolve
function
with
with
capital
c
being
the
original
promise.
Constructor
correct.
B
Okay,
so
if
it's,
if
it's
the
original
promise
constructor,
it
just
returns
the
promise,
if
it's
a
derived
promise,
it
will
adopt
the
promise
in
into
an
original
promise.
C
B
Adopt
using
the
resolve
step,
which
currently
used
the
thenable
mechanism
only
and
doesn't
care
about
the
fact
that
the
original
promise.
C
Oh
yes,
okay,
okay,
good
this
at
least
I
now
understand
I'm
a
little
bit
shocked,
but
I
understand-
and
I
also
understand
that
a
lot
of
this
at
this
point
cannot
be
fixed.
C
I
thought
that,
okay,
there
wasn't
there
discussion
in
committee
about
changing
a
weight
to
short-circuit
something
so
that
it
would
be
faster.
It.
B
Does
where
is
this?
So
if
it's
an
original
promise,
where
does
it
do.
A
C
B
B
If
it's,
but
it
there
is
no
same
value
check,
which
I
thought
there
where
interesting.
So
the
dot
then
is
not
called
in
a
weight.
Only
constructor.
B
Okay,
go
back
to
wait.
What
is
done
with
this
stem
promise?
B
Oh
it
does
do
a
perform
promise
then
so
yeah
it
will.
It
will
call
dot
down
here.
C
B
Right
so
this
will
adopt
without
triggering
a
den,
even
if
it's
overridden.
So
if
there
is
a
own
then
on
and
the
weights,
it
will
not
trigger
interesting.
C
C
It
was
really
a
miracle
that
got
into
es6,
even
the
people
proposing
it
were
mostly
just
you
know,
assumed
it
would
only
get
into
es7,
as
we
would
have
called
it
at
the
time
at
earliest,
and
then,
when
the
committee
kind
of
suddenly
realized.
You
know
we
could
just
put
this
in
es6.
C
I
I
mean
I
I
mean
just
value
judgment
laws.
I
will
say
all
together:
it's
it's
it's!
You
know
it's
a
it's
a
very
positive
miracle,
not
just
that
it
happened
when
it
did,
but
that
it
happened
so
close
to
the
original
vision.
There
is
an
incredible
struggle
of
whether
promises
should
be
melonatic
and
the
the
people
who
came
from
the
malematic
school
who
never
tried
to
use
mom.
C
He
would
never
had
experience
using
non-monetic
promises
and
didn't
understand
the
virtues
we're
just
pushing
so
hard
on
thematic,
and
I
even
put
on
the
table
a
compromise
to
have
two
levels
of
semantics
that
had
so.
You
could
have
one
level
that
was
monotonic
at
another
level
that
wasn't,
and
brendan
fortunately
talked
you
know,
talked
us
all
out
of
that
saying.
No.
The
committee
should
decide,
rather
than
do
both.
B
B
Oh,
let
me
share
the
screen
here.
What
so
so
here
is
an
overrated
and
then
on
the
native
promise.
B
So
I
override
then-
and
the
only
thing
I
do
is
just
like
here
and
then
call
the
original
one-
the
wait
who
doesn't
trigger
the
then
promise
result.
Food
doesn't
trigger
it,
then
because
it
just
short
circuits
and
returns
foo
right
away.
But
here,
if
you
do
an
adoption
through
the
result,
functions
it
will
trigger
the
dot.
Then.
C
B
Over
it
and
then
so,
because
the
adoption
currently
the
result
functions
do
not
test
for
if
it's
a
native
promise
or
not
okay,.
B
A
New
new
promise.
B
A
B
This
will
not
trigger
the
here,
because
it
only
does
it
then
so
it
would
do
one
to
foo,
but
if
we
replaced,
let's
see
it
if
we
replaced
it
with
a
gets.
B
Yeah
so
get
then
and
then
return
or
thing
here
and
then
okay.
So
let's
try
that
again,
yeah
all
right.
B
Good
show,
and
so
a
weight
will
not
do
that
because
it
short
circuits
right.
I
promise.
B
Who
will
not
do
that,
however?
What
we
can
do
is
instead
of
the
then
do
it
for
constructor.
C
C
B
And
here
we
return
promises,
yeah
and
so
promise
result.
Foo
we
get
the
constructor,
I
wait
for
we
get
the
constructor
because
the
trigger
the
same
thing-
and
if
you
do
this
one,
you
do
the
whole
shebang.
C
B
Yeah,
but
just
just
know,
when
we're
out
that
will.
C
C
Okay,
so
this
is,
this
is
a
very,
very
compelling
case
for
promises
promise.
Let
me
mention
some
misgivings
that
I
have,
which
is,
in
general,
we're
trying
to
avoid.
This
was
something
that
was
brought
up.
You
know
discussed
extensively
the
last
tc-39
meeting
we're
trying
to
avoid
built-in
functions
that
do
run
checks
in
internal
slot
checks,
including
brand
checks,
but
internal
slot
usage
of
any
kind
on
arguments.
Other
than
to
this
argument.
C
And
the
reason
is
practical
membrane,
transparency
and
the
reason
why
array
dot
is
array
is
not
a
counter.
Example
is
proxy
special
case
for
it
where,
if
the
proxy
target
is
an
array
that
array
dot
is
array
on,
the
proxy
will
say
true.
B
Yeah
and
I'm
pretty
sure
nobody
will
allow
another
one
of
those.
C
So
that's
probably
true,
but
nevertheless
we
should
still
discuss
whether
we
would
want
it,
and
I
would
argue
in
this
case
we
don't
want
it
because.
C
C
C
B
The
main
argument
currently
against
a
brand
check
is
that
it
would
be
abused
first
to
do
conditional
awaits
people
wouldn't
understand
that
what
they
don't
what
they
care
about
is
a
deniable
check
and
not
a
not
a
is
promised
check,
I
mean,
might
be
able,
I
think
jack
just
suggested
like
to
name
this
is
native
promise,
maybe
make
it
more
obvious
that
it's
not
like
a.
A
A
Yeah
a
data
point
is
that
people
are
suggesting
that
if
promises
promise
existed,
it
would
be
abused.
A
B
People
people
really
want
to
do
conditional
awaits
so
yeah.
B
The
other
thing
I
was,
I
started
going
down
the
path
and
then
I
took
a
wrong
turn,
but
I
think
there's
still
potential.
There
promise
inherits
from
the
object
constructor,
so
we
could
put
a
own
two
string
on
the
promise
prototype
that
does
a
brand
check.
C
And
and
so
what
do,
what
does
it
do
on
each
side
of
the
brandcheck.
B
So
promise
that
prototype.2string
would
do
a
branch
do
a
check
if
this
is
an
object.
If
it's
an
object,
does
a
brand
check
for
his
promise
and
then,
if
it
is,
it
just
returns
the
tostring
tag
if
it
doesn't
pass
the
brand
check.
C
B
B
Right,
correct.
A
B
B
Right,
so
you
could
do
return
promise
string
without
hitting
two
string
tied
if
it's
a
promise.
The
problem
is
that
if
you
fall,
if
it's
not
a
promise,
you
will
still
execute
yeah
yeah,
no,
never
mind
that
yeah.
I
know
we
really
need
a
clean.
We
really
need
a
clean
brand
check
with
no
strings
attached.
C
Okay,
so
I
think
I
think
this
issue
about,
I
think.
A
B
The
pushback
we're
hearing
right
now
is
that
this
is
a
very
niche
use
case.
Most
people
really
shouldn't
care
about
really,
don't
really
don't
care
about
synchronous
interleaving.
There.
C
The
avoiding
synchronous
interleaving,
mostly
in
the
context
of
hardened
javascript
and
endo
and-
and
I
would
like
to
and
the
extra
tick
suggestion
that
you
mentioned
for
e.when-
would
work
but
is
really
expensive.
C
Is
there
something
that
could
that
could
plausibly
work
for
hardened
javascript
for
e.
for
endo
for
e
dot,
when
even
if
it
doesn't
work
in
unhardened
javascript?
C
B
Because
anything
will
trigger
a
get
constructor
or
a
get
there.
B
I
mean
I
mean,
and
the
problem
is
that,
as
we've
seen,
even
a
weight
will
do.
I
mean
it's
probably
less
dangerous,
because
when
you're
awake
like
it's,
it's
literally
the
last
thing
it
will
do.
B
B
Yeah,
which
you,
which
you
hoped
yeah.
B
Does
that
mean
we
need
to
rewrite
all
our
awaits
if
we
can't
trust
what
we're
waiting
and
wrap
them
into
into
a
ewing
or
something.
C
A
C
I
don't
know
I
don't
know.
Async
functions
were
obviously
introduced
after
promises
and
didn't
come
out
of
didn't
come
directly
out
of
our
work.
It
does
come
indirectly
from
you
know,
dean's
work
on
midori,
but
I.
C
A
B
Yeah
and
the
fact
that
the
executor
is
executed,
synchronously
of
the
promise
constructor.
A
And
my
understanding
of
qa
sync
was
that
the
generator
wouldn't
begin
until
the
next
turn
and
I
had
assumed
that
the
syntax
was
the
same.
But
I
don't
know.
C
A
I
don't
know
where
white,
where
we
diverged
or
why.
But
I
got
a
hint
of
that
from
something
you
said
a
while
back
that
you
wanted
to
have
a
weight,
be
the
explicit
delimiter
in
its
absence
to
not
to
not
necessarily
have
a
an
asynchronous
delimiter.
But,
oh,
I
don't
know.
C
So
that
would
that
that
would
I
mean
I
could
argue
that
both
ways,
because
it's
the
the
the
thing
about
marked
interleaving
points-
is
for
straight
line
code
within
a
function
for
the
function
as
a
whole.
Obviously
it
starts
you
know
in
general,
it
starts
when
it's
called
and
generators
already,
don't
start
when
they're
called.
C
A
Yeah,
I
agree
I
I've
shown
my
screen.
This
is
this:
is
the
trick
that
we're
using
to
identify
typed
arrays
with
a
brand
check
that
depends
upon
the
tostring
tag
symbol,
the
behavior
of
the
two-string
tag,
symbol,
which
we
capture
early
and
then
apply
to
typed
arrays
wait.
So
if
we
type.
B
String
tag
is
a
it's
a
getter.
B
Oh,
that
is
the
only
case
where
that
is
the
case,
so
I
mean.
C
B
Yeah,
which,
which
is
what,
which
is
what
I
originally
wanted,
but
then
I
realized
that
I
thought
we
did
just
pick
somewhere,
but
I
couldn't
find
in
the
spec
anywhere
where
two-string
tag
was
a
getter
and
I
apparently
missed
the
type
to
raise.
So
where
is
that
so.
B
I
agree,
but
the
problem
it
would
require
changing
two
string
tag
from
a
value
into
a
getter
which
I'm
happy
to,
because
that
thing
is
probably
not
really
cold.
But
I'm
wondering
if
it
would
break
someone.
B
Data
view:
oh
the
data
view
prototype
data
view
prototype
arrays
database.
No,
where
is
it
where?
Where
are
the
type
terrains?
Oh
sorry,
I'm
not
showing
myself
yeah.
A
Yeah-
and
I
will
also
add
to
the
agenda
that
I
would
love
to
understand-
I
had
a
hair
brain
notion
at
some
point,
probably
while
looking
at
grass
waving
in
the
wind
that.
A
That
at
least
some
kinds
of
property
override
problems
might
be
solved
by
doing
a
drastic
and
probably
inadvisable
measure
of
under
sess,
removing
under
lockdown
removing
all
of
the
properties
of
the
object
prototype
who
needs
them
anyway.
Wait
wait!
What
what
and
I'd
love
to
hear
next
week
about
why
that's
a
bad
idea.
A
I'm
not
I
I'm
not,
but
that's
only
because
I
haven't
thought
it
through
and
I
could
use
some
help
from
that
next
week.
Maybe
all
right
on
that
note
having
outed
myself
as
a
naive
fool,
I
think
that's
a
great
place
to
stop.