►
From YouTube: SES-mtg: Records and Tuples, part 2
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).
B
Excellent,
so
wait.
Maybe
we
should
start
now
that
we're
recording
by
framing
the
discussion.
Yes
talking
about
the
the
idea
that
records
and
tuples
rather
than
being
primitives,
would
be
objects
but
objects
without
identity
that
are
conf
that
are
compared.
You
could
think
mark
framed
it
as
they're
compared
shallowly
for
equality
at
that
particular
level
they're
compared
by
what
they
contain
and
then
recursively.
The
comparison
continues.
B
So
if
it
contains
another
record
it
recurses
down,
but
it's
not
necessarily
deeply
the
same
thing,
because
you
can
opt
out
of
using
records
and
tuples
and
just
use
normal
objects.
So
there
there's
kind
of
two
two
fundamental
questions
we
were
talking
about.
One
of
them
do
we
still
need
box,
or
can
we
just
let
you
use
objects
wherever
you
want?
The
other
fundamental
question
is:
do
we
want
to?
Is
it
okay
to
split
up
the
notion
of
sort
of
what
a
primitive
is
in
two
like
this?
Where
primitive?
Is
these
two
things?
B
One
thing
is,
it
has
wrappers
and
the
other,
and
the
other
thing
is
that
it
has
value
equality
and
now
we're
saying
these
things
have
value
equality,
but
they
don't
have
wrappers.
So
this
breaks
with
the
way
we've
been
discussing
it
for
a
long
time
and
it
could
break
with
some
people's
mental
model.
I
wanted
to
explicitly
discuss
whether
that
was
okay,
even
though
you
didn't
raise
it
as
a
concern.
C
You
know
so
let
me
give
a
little
background
on
the
distinctions
that
we
made
in
the
e
language,
and
can
everybody
see
my
screen
with
the
with
the
graph
with
the
the
graph
with
the
red
and
the
orange
okay?
So
we
had
this
taxonomy
of
restricted
forms
of
objects,
and
the
word
frozen
here
does
not
mean
what
it
means
in
javascript.
C
The
term
frozen
here
is
just
shallowly
immutable,
so
a
frozen
object
could
contain
non-frozen
objects
and
then
the
qualifier
deep
on
these
various
you
know,
the
the
adjective
deep
prefix
to
things
like
deep
frozen
means
that
whatever
the
restriction
is
that
restriction
applies
deeply.
So
a
deeply
frozen
thing
would
be
one
that
transitively
has
no
mutable
state
within
it,
and
an
immutable
state
has
no
ability
to
to
cause
or
sense
effects
in
it.
C
C
So
an
object,
that's
selfless
would
would
compare
based
on
comparing
the
components,
doing
a
structural
comparison
and
once
again
an
object
could
be
shallowly
selfless
selfless.
The
arrows
here
are
an
implication.
If
it's
selfless,
then
it's
necessarily
frozen.
It
doesn't
make
any
sense
to
do
a
structural
comparison
if
the
things
that
you're,
if
the
things
that
you're
comparing
could
be
mutated
on
one
and
not
the
other,
that
would,
if
a
structure
comparison
then,
would
give
you
unstable
answers
the
for
every
deep
form.
C
The
deep
form
implies
the
shallow
form
in
that,
if
you're
deeply
frozen,
you
must
be
frozen
and
then
pass
by
copy
was
a
further
description
once
again
in
shallow
and
deep
form
where,
in
order
to
be
passed
by
copy
this
and
pass
by
copy,
as
the
name
implies
had
to
do
with
computing
across
address
spaces.
C
But
the
issues
that
dan's
raising
about
membranes,
I
think
the
pass
by
copy
notion
is
also
a
good
way
to
think
about
what
happens
with
these
things
across
membranes,
which
is
that,
rather
than
having
a
proxy
on
one
side
for
the
wheel
of
thing
on
the
other
side,
you
just
get
a
complete
duplicate
on
the
other
side
of
the
membrane
which
can
be
independent
or
you
just
share
them
as
if
and
they
have
the
same
semantics
as
if
they're
duplicated
the
main
constraint
on
a
path
by
copy.
C
The
semantic
constraint
is
that
a
complete
copy
of
it
cannot
be
distinguished
from
the
original.
If
you
have
the
original
and
the
copy,
then
there's
no
way
to
distinguish
that
what
you
have
as
a
copy,
rather
than
two
references,
the
same
original.
So,
in
this
regard,
let's
say
a
javascript
string
which
might
be
duplicated
on
the
heap,
is
passed
by
copy
because
there's
no
way
to
tell
in
javascript
that
it's
a
copy
of
the
string
rather
than
the
same
string.
C
C
There
were
two
further:
there
was
a
further
restriction,
besides
being
selfless,
it
had
to
be
transparent,
meaning
that
it
doesn't
encapsulate
anything,
and
I
see
that
dan's
proposal
also
knew
gets
at
some
of
those
same
constraints
as
well,
which
is
the
stuff
that's
being
duplicated
in
order
to
be
duplicated
needed
to
not
be
hidden
so
that
a
membrane
layer
or
or
a
marshalling
layer
could
reproduce
it.
C
On
the
other
side,
to
make
the
copy
and
transparent
and
e
broke
up
into
open
state
and
open
source,
meaning
the
data
values
and
the
code
which,
in
dan's
world
is
sort
of
the
the
fields
versus
the
class
or
the
fields
versus
what
it
inherits
from
the
proto-pointer
or
or,
and
also
actually
open
source,
also
has
to
do
with.
C
Is
there
behavior
that
comes
along
for
the
ride,
and
that
opens
a
bunch
of
interesting
questions
and
then,
if
you
had,
if
you
know
for
any
of
these
things,
if
they
were
true
transitively,
you
could
test
at
the
root
of
any
such
subtree.
Is
this
you
know?
Is
this
transitively
stable
in
this
way?
You
have
a
predicate
for
each
of
these
restrictions,
including
the
predicate
for
the
deep
form.
So
you
can
actually
tell
that
the
thing
that
you've
got
is
is
a
transition
is
transitively
whatever.
B
C
Yeah
and
one
of
the
nice
things
for
us
in
our
world
of
of
multiple,
you
know
vats
or
workers,
sharing
an
address
space
and
wanting
to
do
wanting
to
pass
structures
when
you're
sharing
an
address
space
is
if
something
is
deeply
frozen,
then
it
might
also
be
thread
safe.
C
You
could
have
two
vats
two,
you
know
essentially,
workers
in
javascript
terminology
sharing
an
address
space
and
when
you
did
a
a
message
pass
between
them,
the
message
pass
would
have
the
semantics
of
the
same
semantics
as
doing
a
message
pass
between
address
spaces,
except
that
when
it
saw
that
something
was
deeply
frozen,
it
would
just
pass
it
by
pointer
sharing,
rather
than
passing
it
by.
C
So
you
could
do
large,
deep
data
sharing
without
without
copying
overhead,
if
you
happen
to
be
in
the
same
address
space.
B
Yeah
so
the
thing
about
thread
safety.
B
That
was
something
that
I
discussed
with
some
javascript
engine
maintainers
and
they
saw
it
kind
of
in
contradiction
with
the
optimizability
of
recursive
equality,
which
is
an
important
feature
of
records
and
tuples,
because
you
need
an
intern
table
and
just
synchronizing.
The
intern
table
across
threads
within
the
same
process
is,
is
prohibitively
expensive.
So
it
makes
the
reliable,
cheap
equality
impossible.
So
what
I
expected
that
records
and
temples
would
be
copied
across
threats
rather
than
but
but
actually
the
discussions
made
me
very
optimistic
that
we
may
actually
get
reliably
fast
equality.
C
I
love
the
hash
counseling
idea.
These
ideas
are
not
in
conflict
the
when
you
receive
so
so
there's
two
ways
to
approach
it.
One
is
to
intern
on
reception.
Where
you
check
you,
you
walk
on
reception,
you
walk
the
structure
and
say
for
for
any
substructure
here.
If
I've
already
got
it
in
my
local
interning
table,
I'm
going
to
use
that
one,
but
otherwise
I
don't
need
to
make
a
copy.
Otherwise
I
can
take
the
one
that
I've
received
and
use
that
as
the
one
I'm
interning.
C
B
Oh,
that's
an
interesting
idea,
I'll
mention
it
to
them,
but
the
other
thing
is
that
some
javascript
just
have
a
single
threaded
gc
and
they
they
they
keep
isolation
by
thread.
C
B
So
I
think,
for
records
and
doubles
we'll
just
coordinate
expectations
among
javascript
programmers
that
like
for
now,
they
use
per
thread
gcs
thanks
for
mentioning
this
technique
for
the
intern
table
I'll
mention
that
to
the
implementers
and
we'll
just
have
to
you
know,
but
we'll,
but
we'll
still
try
to
coordinate
expectations
that
look.
B
If
you
do
pass
these
to
another
thread,
it's
going
to
be
copied
for
now,
because
that's
what
js
engines
do
with
their
birthrate
pc
they,
the
v8
team,
says
that
it
has
potentially
security
benefits
to
have
per
thread
gc
because
it
decreases
sort
of
the
surface
area
that
you
know
that
the
threads
interact
with
each
other
so
or
or
integrity
benefits.
It's
you
know
talking
about
what
security
means
you
know.
C
Yeah,
so
I
thought
so
I
think
that's,
that's
a
that's
a
valid
point.
So
what
this
does
is
it's
like
the
the
stance
we
were
taking
on
interning
in
the
first
place,
which
is
we're
not
guaranteeing
interning
we're
leaving
up
to
the
implementation,
but
we're
creating
a
semantics
that
gives
the
implementation
that
choice
this
would
we
could
simply
take
the
same
stance
with
regard
to
copy
avoidance
when
you're
passing
between
threats.
B
C
Okay,
but
that
guidance
on
the
side
seems
fine,
it
would
still
be.
I
still
think
I
do
think
that
having
the
semantics
be
one
that
gives
the
option
of
that
optimization
yeah
in
any
case,
the
main
point
here
is
not
the
optimization
main
point
here
is
that
it's
a
very,
very
clean
semantic
model
and
we're
reproducing
a
lot
of
this
in
in
a
restricted
form
for
javascript
and
agorak
that
I'm
gonna.
C
Now
show
off
over
here,
which
is:
we've
got
this
in
the
when
we
do
distributed
javascript
computing,
we're
passing
javascript
objects
between
vats.
C
C
C
C
C
The
let
me
come
back
to
the
promise
case,
because
that
one
we're
probably
doing
something
that
we
don't
want
to
reproduce
in
your
proposal.
But
it's
an
interesting
question.
C
Obviously,
if
their
past
files
are
different,
then
the
answer
same
structure
is
false.
If
it's
any
of
the
primitives,
then
we
just
use
the
same
value,
zero
semantics.
So
in
that
regard
we
already
arrived
at
the
same
place.
C
We
have
copy
record
and
copy
array,
which
is
really
very
much
like
you
know
very
analogous
to
the
record
in
tuple
the.
In
order
for
something
to
be
considered
a
copy
record,
it's
it
had.
Well,
we
have
a
bunch
of
restrictions
on
it
that
are
not
necessarily
the
ones
that
we
want
to
reproduce,
but
basically
it's
inherits
directly
from
object.prototype.
C
C
An
interesting
question
is
whether
we
want
to
allow
immutable
shallowly
immutable
cycles
can,
and
even
if
we
don't
want
cycles,
do
we
allow
dags.
I
think
we
probably
don't
want
to
allow
cycles,
but
we
do
want
to
allow
dags
and
for
dags
you'd
like
to
have
the
cost
of
the
comparison.
C
B
C
Good
good,
so
so
the
your
notion
of
the
proxy
record
or
the
record
proxy
first
of
all,
did
you
mean
to
to
restrict
that
to
records,
or
do
you
mean
to
also
include
tuples.
B
B
Was
that
the
design
there
was
completely
broken
because
we
need,
in
addition
to
the
handler
we
need
sort
of
a
payload
for
the
handler
which
could
be
the
this
sent?
Is
the
this
value
to
the
handler
methods,
because
normally
the
handler
would
close
over
some
something,
and
so
we
would
need
sort
of
a
third
argument
to
that.
C
Right
so
I
think
the
notion
of
shallow
equality
is
the
thing
that
really
saves
you
here,
which
is
the.
If
you've
got
a
I'm
sorry,
shallow,
selflessness
or
shallow.
C
C
Yeah,
perhaps
it
does
have
identity,
but
the
idea
of
a
proxy
that
is
exactly
the
current
proxy,
except
that
comparing
it
recursively
does
the
same
value,
zero
comparison
on
its
handler
and
target,
and
then
the
handler
and
target
could
in
turn
be
shallowly
immutable
things
in
which
case
it.
Just
you
just
continued
the
recursion
or,
if
they're,
not,
then
the
recursion
stops,
because
that's
the
leaves
that
then
then
then
the
target
and
the
handler
become
the
leads
of
your
shallow
comparison.
D
But
I
have,
I
have
multiple
conversations
with
danielle
this
week
about
these.
D
I'm
still
confused
about
a
few
things
around
these,
and
I
also
have
some
concerns
that
I
expressed
somehow
specifically
the
biggest
concern
that
I
have
is
that.
D
If
we
do
a
special
kind
of
proxy
for
records
and
tuples,
and
that
means
you
have
to
do
the
extra
work
of
being
defensive
about
the
objects
that
are
being
handed
to
you.
Because
you
don't
know.
If
it's
going
to
be
one
of
these
things,
especially
you
want
some
sort
of
a
special
behavior.
But
that's
fine.
C
Okay,
so
what
is
so,
let's
say:
you're
expecting
a
regular
object
and
you
received
a
a
a
record
or
you
received
a
proxy,
a
selfless
proxy
whose
target
object
was
a
record.
If
you
were
right,
if,
if
the
code
that
received
it
would
just
express
it
expecting
a
normal
object,
what
would
be
the
hazard.
D
Right
so
I'm
about
I'm
about
to
get
to
that
I
mean,
let
me
complete
a
sentence
so
based
on
on
on
the
assumption.
My
assumption
is
that
we
don't
need
any
special
type
of
proxy
for
these
and
I'm
trying
to
articulate
why.
I
don't
think
I
think
so
so
if
you're
you're,
putting
a
proxy
around
a
record
and
and
that
record
is
an
object
that
has
no
identity
whatsoever,
describe
it
in
the
gist
from
from
daniel
the
independently
of
what
the
handler
is
doing.
D
If
the
target
of
the
proxy
is
a
a
record,
you
don't
even
need
to
check
the
handler
to
know
what
the
output
of
that
will
be,
because
in
order
to
keep
the
the
the
invariance
the
object
invariant
the
since
the
record
has
everything
frozen,
non-configurable,
not
writable,
then
all
the
outputs
of
the
handler
should
be
consistent.
With
the
current
record
that
you
have
that's
one
thing.
B
We
might
have
to
make
the
record
the
record
fields
configurable
and
not
and
make
the
record
not
sealed
in
order
to
get
around
that.
D
Before
we
get
to
that,
like,
I
would
like
to
first
understand
what
why
they
need
to
be
configurable
and
so
on,
because
we
overcome
these
limitations
by
introducing
the
shadow
target
instead,
and
if
you
bring
a
shadow
target
into
the
picture,
then
I
I
don't
see
a
big
problem
there,
where
you
still
have
a
shadow
target.
You
still
have
a
handler
that
is
associated
somehow
to
a
to
the
record
and
with
the
trap
there.
D
B
D
So
if
the
shadow
target,
which
is
normally
the
same
type
of
the
target,
so
if
you're
creating
a
a
proxy,
a
membrane
proxy
of
a
function,
the
shadow
target
should
be
a
function,
you're
creating
a
regular
object
and
it
should
be
an
object.
If
it
is
an
array,
it
should
be
an
array,
because
that
helps
you
with
some
other
tests.
That
might
happen
against
that
proxy.
D
C
The
okay,
so
when
you
say
the
record
is
record
check
so
in
a
world
of
shallow
immutability,
what
are
the
guarantees
that
follow
from
the
record
as
record
check
once
I
take
an
object
and-
and
I
do
a
record
as
record
on
it
and
and
the
answer
is
true.
B
C
No
but
my
the
the
issue
about
what
guarantees
follow,
I
think,
is
really
sort
of
the
core
the
way
I
would
approach
the
question
that
coridia's
asking
is:
if,
for
a
non-proxy,
a
non-record
proxy,
just
a
regular
record?
C
If,
but
in
a
world
of
shallow,
you
know
shallow
selflessness
rather
than
deep,
sharp
selflessness
that
we're
not
talking
about.
C
If
I
do,
a
record
is
record
check
and
the
answer
is
true
and
I
make
some
assumptions
because
the
answer
is
true,
then
I
would
want
it
to
be
the
case
that
if
I
did
it
on
a
record
proxy
instead
and
the
answer
was
still
true-
that
the
same
guarantees
would
follow.
I
don't
want
the
record
practice
to
great
getting
guarantees
that
I
would
be
assuming
for
a
regular
for
a
normal
record.
D
Exactly
so,
if,
if
I
create
it,
if
that's
a
thanks
mark,
I
think
that
that's
the
gist
of
my
question,
like,
in
my
opinion,
if
you're
going
to
create
a
proxy
out
of
a
record,
even
if
you're,
using
the
shadow
tag
tricks,
you
still
need
to
do
a
lot
of
work
to
produce
a
shadow
target
that
actually
guarantees
the
same
things
that
will
be
guaranteed
once
you
know
that
the
actual
target
is
a
record.
D
C
D
Yeah
shadow
target
for
frozen
optic
is
still
possible
yeah.
I
would
say
that
yes,
this
is
the
same
that
we
do
today.
B
I
thought
we
would
want
to
be
able
to
do
distortions
over
the
box
cleaned.
You
know.
D
C
C
C
The
for
the
shallow
ones
yeah,
so
here's
something
interesting,
which
is
if
we've
got
a
predicate
where
we
can
in
constant
time-
and
you
know
in
you
know,
developer
expected
constant
time
using
your
your
same
notion
of
advice
rather
than
mandate.
But
if
in
developer
unexpected
constant
time,
you
can
check
that
this
is
a
deeply
selfless
structure.
C
Deeply
self-destructor
should
be
able
to
just
pass
through
the
membrane,
as
is,
if
you
don't
care
to
distort
it
and
once
again
that
sort
of
goes
back
to
this
diagram,
where
it's
only
the
deeply
frozen
things
that
can
be
passed
between
address
spaces
by
pointer,
sharing,
something
that's
shallowly
frozen
has
to
be
duplicated
because
the
things
that
are
at
the
leaves
have
to
be
passed
by
other
means.
C
And,
and
going
across
the
membrane,
I
think
I
think
this
you
know
more
and
more
convinced
me
that
going
between
address
spaces
or
between
threads
or
across
membranes
is
very
much.
Those
three
cases
are
really,
you
know
very
equivalent
in
many
ways.
It's
it's
only
if
you're,
you
know
deeply
identically
less
that
you
can
just
go
through
the
membrane
without
without
any
copying
overhead.
B
I
see
so
dennis
the
so
I'm
sorry
for
very
sorry
for
interrupting
you
before
dirty,
so
it
sounds
like
we
should
just
make
them
be:
have
the
the
property,
descriptors
or
frozen
objects,
and
not
have
them
be
sort
of
looser
in
some
way,
because
it's
okay
to
do
the
copy?
So
if
you,
if
you
have
a,
if
you
have
an
object,
nested
in
a
nested
record
in
temple,
basically
you
have
to
copy
the
path
to
the
object.
You
don't
have
to
copy
the
whole
nested
structure.
C
Not
talking
I'm
talking
about
getting
rid
of
them,
no,
no!
So
so
pretty,
I'm
not
sure
if
you,
if
you
were
here
at
the
beginning,
what
I'm
suggesting
is
that
we
get
rid
of
the
box
notion
completely,
and
we
just
say
that
we're
no
longer
talking
about
deep
immutability,
we're
talking
about
in
general
objects
that
are
shallowly
immutable
and
without
identity,
but
where
the
leaves
of
the
so
basically
talking
about
a
a
identity-less
superstructure
where
they
say
the
identity
of
the
superstructure
is
also
immutable.
C
But
then
the
leaves
of
the
superstructure
are
just
regular
objects.
It
can
be
any
other.
Javascript
value
is
when
you
reach
something
other
than
an
identical
lease
object.
Then
you're
at
the
leaf
of
the
identity,
identity-less
superstructure
and
the
things
which
are
deeply
identity-less
are
the
ones
that
don't
have
any
leaves
that
don't
have
you
know
in
which
in
which
the
only
leaves
are
predators.
C
And
so
so
that
gets
rid
of
the
notion
of
box.
C
So
so
the
the
it
is
consistent
with
the
shallow
perspective
that
a
identity
that
two
different
identities
objects
could
share
a.
C
Object
as
the
value
of
their
food
property,
so
the
the
dunder
proto
pointer
itself
would
have
to
be
a
a
fixed
pointer,
as
as
you
would
get
on
a
non-extensible
object.
So
the
object
would
be.
You
know
for
an
object
to
be
identity-less
and
shallow
or
immutable
it
would
have
to
be.
You
know
all
of
its
properties
would
have
to
be
non-configurable
non-writable
and
it's
the
object
as
a
whole
would
have
to
be
non-extensible
but
and
therefore,
which
object
that
inherits
firm
is
fixed,
but
that
object
could
be
a
regular
object.
D
C
So,
okay,
so
that
so
then
so
that
becomes
a
question
goes
back
to
the
question
of
what
are
the
guarantees
that
we
want
to
follow
from
right,
right
right
and
if
we
want
so
so,
the
the
the
straightforward
notion
of
record
that
I
was
just
stating.
C
I
would
say
that
your
only
guaranteed
equivalence
of
of
own
properties.
Are
you
only
guaranteed
stability
of
own
properties
that
inherited
properties?
You'd
still
be
inheriting
them
from
the
same
object,
but
but
that
object
could
be
mutated.
C
If
the,
if
we
had
a
predicate
for,
is
deeply
immutable,
then
everything
at
all
levels
that
you
reach
from
the
object
would
have
to
be
stable.
I
could
imagine
that
we
that
for
javascript
the
the
inheritance
issue
is
is
arises.
That
was
not
an
issue
for
e.
C
I
could
imagine
that
we
had
something
that
was
defined
as
another
predicate
for
just
transitively
up
the
prototype
chain,
but
not
transitively
across
properties,
so
that
and
then
that
would
apply
to
all
properties
on
the
object,
whether
own
or
inherited,
but
would
still
not
apply
to
things
reached
by
navigation
from
those
properties.
You
know
reply
to
dot
foo.
It
would
still
multiply
the
dot
true
dot
bar
and
then,
if
it
was
really
transitive,
then
it
applies
not
just
to
dot
foo,
but
it
applies
to
the
dot
through
dot
bar.
D
So
that's
I
mean
I
I
have
to
think
more
about
this,
but
in
principle
I
think
my
biggest
issue
is
going
to
be
for
developers
because
there
are
certain
expectations
and
and
using
own
properties
only
as
the
thing
that
you
can.
C
Trust,
so
it
might
be
that
the
that,
if
we
had
all
three
of
those
predicates
that
the
one
we
would
that
the
one
that's
own
only
is
one
that
we
would
consider
to
be.
The
more
obscure
predicate
and
the
ones
that
we
promote
from
normal
use
are
the
ones
that
are
present
about
the
prototype
chain
and
the
ones
that
are
that
are
completely
transitive
through
all
navigation.
B
I
think
we
have
to
be
really
careful
about
the
set
of
predicates
that
we
expose,
because
I
think
if
we
expose
like
all
of
these,
it's
going
to
be
unintelligible.
We
have
to
you
know.
I
don't
know
whether
the
I
mean
I
see
that
the
argument
for
exposing
both
shallow
and
deep
ones
and
promoting
people
to
use
the
deep
ones,
but
I
feel
like
there's
some
risk
to
it.
C
Okay,
so
let's,
let's
explore
the
possibility
that
I
think,
is
what
queer
is
getting
at,
which
is
that
the
shallow
immutability
is
still
transitive
up
the
protection
that,
if
you're,
if
you're
frozen,
if
you're
not
frozen,
if
you're
immutable,
if
you're,
if
you're
identity
free,
then
necessarily
your
dunder
proto,
is
identity,
free
and
and
therefore
recursively
change
from
there.
B
Note
that
tuples
don't
meet
this
property
and
we
decided
that
it
was
very
important
that
doubles
do
have
a
mutable
prototype,
because
if
we
do
want
to
add
methods
to
it,
the
other
another
case
is
temporal.
If
we
wanted
temporal
to
be
modeled
by
something
identity-less,
which
I
think
would
be
useful,
this
would
prohibit
monkey
patching
on
temporal
which
for
this,
which
we
would
probably
want
to
be
able
to
do
for
the
same
reason
as
we
want
to
be
able
to
do
it
for,
for
you
know,
for
tuples.
B
I
also
want
to
mention
this
open,
open
state
property.
If
we
wanted
to
model
temporal
as
something
open
as
something
passed
by
copy
temporal
has
internal
slots
and
those
internal
slots
they're
not
they're,
they're,
not
transparent,
and
so
they,
I
think,
they're
still
meaningful
and
there's
still
a
meaningful
sense
of
selflessness,
but
it's
not
transparent,
and
I-
and
I
kind
of
feel
like
the
core
of
records
and
tuples
is,
is
selflessness
in
this.
C
So
so
you
that
that
is
a
as
you
see
on
on
my
diagram
past
by
copy
is
a
stronger
constraint
than
selfless
and
you
can
have
selfless
objects
that
are
not
transparent,
but
those
things
don't
pass
by
copy
in
order
to
pass
by
copy
you
have
to.
You
have
to
be
transparent
so
that
the
so
that
some
intermediate
player
can
access
everything
it
needs
to
copy
the
I.
C
If
we're
going
to
collapse,
distinctions
which
for
javascript,
I
think,
makes
perfect
sense,
then
I
think
you
know,
then
we
have
to
choose
what
distinctions
we're
collapsing,
but
I
think
that
you
can't.
C
I
noticed
in
your
proposal
when
I
liked
in
your
proposal
that
the
things
which
were
immutable
don't
have
hidden
stake,
even
hidden
immutable
state
and
and
the
fact
that-
and
you
know
that
you
can't
add
the
state
with
return
override.
C
The
fact
that
return
override
can
be
modeled
with
weak
maps
is
a
consistent
stance
in
your
proposal,
because
you
also
can't
use
these
things
as
keys
and
weak
maps.
Yeah.
B
That
that's
true,
but
I
would
like
to
be
able
to
expand
to
having
private
fields
in
records
and
tuples
like
if
we
made
it
so
that
you
could
use
private
fields
and
object
literals,
which
I've
adjust
for.
If
anybody's
curious,
then
then
I
would
want
to
be
able
to
use
those
in
records
also,
but
do
you
think
that
that's
a
bad
idea
because
it
would
not
be
transparent
so.
C
The
in
ee,
although
we
had
the
option,
as
you
can
see
on
the
table,
things
that
were
selfless
that
were
not
passed
by
copy
in
practice.
We
never
made
use
of
that.
Likewise,
in
our
distributed
object
system,
you
can
create
something
that
looks
to
the
com
system
like
pass
by
copy,
but
which
actually
does
have
other
encapsulated
state,
because
these
objects
being
javascript
right
now.
C
Normal
javascript
have
object
identity,
so
you
can
associate
private
statements
through
weak
maps,
but
in
practice,
what
we
do
is
we,
we
sort
of
bifurcate
the
world
to
objects
that
are
just
acting
like
structured
data,
which
are
in
very
much
the
same
way
that
you
pass.
You
know
json
data
around
and
you
just
think
of
them
as
data
you
don't
think
of
them
as
engaged
in
procedural
abstraction
engaged
in
object,
abstraction
and
then
you've
got
objects
with
methods
that
encapsulate
state
that
have
identity
and
pretty
much.
C
You
know
having
given
ourselves
an
e
this
very
fine
taxonomy.
What
we
ended
up
using
is
just
the
bifurcation
that
you've
got
immutable,
transparent
identity,
free
data
and
you've
got
objects
with
methods
and
identity,
and
I
think
that's
the
sweet
spot.
B
So
I
I
think
I
mean
records
and
temples
definitely
operate
to
the
intersection
between
this
because
they're,
not
they
don't
allow
any
hidden
state.
But
I
would
like
to
think
about
future
extensions
where
we
are
using
hidden
state.
I
mean
record
proxies,
there's
no
way
to
get
at
the
at
the
target
directly,
but
maybe
if
we
say
that
there's
no
payload
there's
just
no
way
for
them
to
hold
anything
sort
of
significant
and
if
they're,
if
the
target's
already
frozen
for,
but
then,
if
we
think
about
things
like
temporal
or
even
decimal.
B
If
you
wanted
decimal
to
be
this
kind
of
selfless
object
because
it
solves
the
wrapper,
it
could
solve
the
wrapper
identity
issue
because
you
just
say
the
prototype
is
pointed
to
by
the
decimal
value.
So
we
don't
need
to
maintain
another
map
off
the
side,
from
brands
to
prototypes
that
could
be
maintained
by
lexical
scope
and
we
could
make
it
work,
but
it
could
be
kind
of
inefficient
to
have
to
go
through
that
extra
mapping.
C
Let
me
clear
up
something
that
I
think
is
important
here,
which
is
in
the
records
and
tuples,
and
the
value
types
proposal
built
on
the
mutable
prototype.
C
Behavior
was
the
reason
it
was
not
a
conflict
for
those
things
to
be
mutable,
for
the
prototype
that
provided
behavior
to
be
mutable
is
that
the
value
did
not
bind
the
prototype.
C
It
was
on
dereferencing
the
value
just
like
with
script.
When
you
do
stream.
C
And
then
you
have
the
brilliant
insight
that
you
could
make
value
types
with
behavior
possible
by
going
fully
lexical
on
that
notion
of
binding
between
the
value
and
the
code
that
it
inherits
from.
B
Right
so
as
I've
chatted
with
more
people
about
that
fully
lexical
idea,
I
get
the
feeling
that
it
would
be
kind
of
implementation
hostile
because
you
need
both
the
brand
in
the
object.
I
mean
in
the
value
not
in
the
object,
and
you
also
need
the
this
lexical
mapping,
which
is
somehow
efficiently
maintained
code
that
compiles
against
this
has
to
account
for
the
fact
that
you
may
run
it
multiple
times
with
different.
B
C
Say
if
it's
the
same,
you
say
the
same
color
we're
talking
about
the
this:
the
same
source
code
having
been
evaluated
multiple
times,
we're
talking
about
the
same
evaluation
of
the
same.
B
Source
source
location
you
could
have
you
know
you
can
use
this
locally
in
a
function
based
on
arguments
to
the
function.
So
multiple
invocations
of
the
same
function
could
have
different
mappings
for
how
the
two
object
of
a
value
type
works.
B
So,
ultimately,
I'm
I'm
a
little
bit
worried
that
this
could
be
too
expensive
and
that
it
could
be
better
for
to
for
us
to
use
selfless
objects
that
actually
point
directly
to
their
prototype
in
order.
C
C
So
so
we
definitely
have
a
you
know
attention
here,
given
that
we're,
starting
with
by
giving
up
on
saying
that
you
know,
but
if
we're
starting
by
giving
up
on
the
notion
that
that
the
only
notion
of
of
selfless
mutability
we
have
is
the
deep
one
giving
up
that
and
we're
allowing
shallow.
C
Then
the
question
is
what
kind
of
shallow
topologies,
what
kind
of
what
kind
of
boundary
between
the
identity
free
immutable
world
and
the
leaves
are
we
allowing
and
if
a
identity
free
object
can
have
an
identity
full
under
proto,
then
we
lose
the
dot
food
guarantee.
That
correctly
was,
you
know
was
warning,
but
we
do
it
yes,
but
we
have
the.
So
it's
just
it's
it's.
We
have
those
options,
but
it's
a
tension.
We
can't
make
the
tension
go
away.
We
have
to
make
some.
B
C
I
think
I
think,
I
think
the
records
and
top
of
proposal
that's
on
the
table.
We
we
would
want
to
withdraw
if
we're
going
in
this
direction,
because
those
records
and
tuples
are
not
objects,
they're,
primitive
values
and
we-
and
I
think
that
the
language
should
not
have
both.
If
we're
going
to
pursue
shallowly
immutable
identity,
free
objects,
then
we
should
kill
the
current
records
and
tuples
as
primitive
values.
B
C
B
Syntax
and
all
the
all
the
we
did
a
lot
of
design
work
about,
like
the
definition
for
equality,
the
standard
library
for
tuples
all
that
carries
over
actually
like
very
little
user
code.
That
would
change
the
only
the
only
normal
path
that
users
would
get
to,
whether
it's
a
primitive
or
an
object
is
when
they
do
type
of
so
that
leads
to
the
obvious
question
of:
should
identity
list
objects
have
a
different
type
of.
C
So
I
think
not.
I
would
recommend
that
that
the
type
of
them
is
still
just
a
string
object,
because
there's
a
tremendous
amount
of
code
out
there.
That
says:
if
it's
not
type
of
object
or
type
of
function,
then
it
must
be
a
primitive
value.
C
So
there's
there's
only
two
type
of
values
that
are
not
primitive
and
I
think
there's
a
lot
of
code
out
there.
That
makes
use
of
that
the,
but,
but
the
deeper
issue
here
is
that
the
current
records
proposal
has
this
binding
on
use
to
a
prototype,
and
that
is
incompatible
with
the
notion
of
a
shallowly.
C
Immutable
object
binding
its
prototype,
whether
the
prototype
is
selfish
or
selfless.
It
would
still
be
the
case
that
it's
the
object
that
carries
the
prototype.
The
prototype
is
not
determined
at
the
point
of
use
and
that's
a
huge
difference.
Difference
from
the
current
records
in
public
proposal.
A
Can
I
step
in
for
a
second
about
the
compromise
and
why
tuples
have
a
mutable
prototype,
so
to
my
knowledge,
nobody
disagrees
with
shallowly
immutable
prototypes
in
this
call,
I
think,
we're
all
agreed
the
ability
to
have
guaranteed
property
access
is
nice
and
things
of
that
nature
for
tuples
they
have
a
different
set
of
integrity,
guarantees
than
records
for
records.
We've
talked
about
string
keys,
in
particular
being
what
integrity
is
guaranteed
for
tuples.
A
Unlike
arbitrary
string
keys,
we
only
have
a
subset
of
that.
We
have
the
subset
being
these
index
properties,
which
we
are
not
desiring
people
to
be
able
to
put
index
properties
on
the
prototype
of
a
tuple.
A
Yes,
which
I
believe
we
simply
must
do
so,
although
the
tuple
is
an
exceptional
special
case-
that
it
does
eventually
get
to
a
mutable
prototype,
I
don't
think
we
need
it
to
be
more
than
a
special
case
and
I
am
not
keen
on
special
casing,
tuples
to
always
inherit
from
a
mutable
prototype,
but
I
don't
necessarily
think
it's
fatal,
because
we
still
maintain
our
integrity
about
what
you
can
do
with
guarantees
that
we're
trying
to
achieve
for
tuple.
C
So
there's
I
mean
there's
still
the
tension
where
the
old
tuple,
the
tuple
itself,
did
not
bind
and
bind
in
the
prototype.
The
prototype
was
bound
at
the
point
of
use.
The
new
tuples
that
we're
talking
about
would
necessarily
bind
in
the
the
prototype,
the
object
they
inherit
from
and
then
we've
got.
Then
we
have
to
circle
around.
To
you
know
korea's
question,
which
is
in
order
to
be
shallowly
mutable.
C
Do
you
have
to
be
shallowly
immutable
up
the
prototype
chain?
Because
if
you
know,
if
tuple
t
were
shallowly
immutable-
and
I
had
a
you
know-
is
this
you
know
is
you
know-
is
one
of
these
identity
free
things
and
the
answer
is
yes,
then,
even
though
I
would
have
integrity
for
p
sub
three,
if
I
don't
have
integrity
for
t
dot
foo,
then
I
don't
have
you
know,
then
shallow
immutability
is
still
not
giving
me
integrity
for
dotsu.
A
This
is,
I
think
I
may
be
misunderstanding,
something
because
this
level
of
call
site
usage
guarantee
of
integrity
is
not
true
for
any
of
the
like
primitive
types.
We
currently
use
that
produce
object,
wrappers
right.
C
But
the
thing
is,
the
primitive
value
doesn't
bind
in
the
prototype.
The
prototype
is
determined
at
the
point
of
use
and
that's
also
true
for
the
current
tuples
before
we
we
make
them
objects
and
that's
fine,
because
it's
not
it's
not
part
of
the
value,
it's
determined
at
the
point
of
views.
So
if
you
pass
it
to
a
different
context,
then
the
other
context
would
look
up
a
different
prototype,
because
the
the
value
doesn't
carry
its
prototype.
B
So
I
I
want
to
emphasize
I
do
I
do
value
this
sense
of
integrity
that
bradley
mentioned,
and
I
wanna
figure
out
how
we
can
square
it
with
potential
other
types
that
things
that
we
might
want
to
make
identities.
B
B
Property
keys
are
forwarded
up
to
the
prototype,
and
so
I'm
just
thinking
about
how
we
could
generalize
this
if
we
want
to
make
value
classes
or
or
record
classes,
maybe
more
accurately,
if
there's
selfless
objects,
and
I
think
it
could
be
something
like
the
record
classes
would
have
fields
and
those
fields
would
be
the
domain
that
we
guarantee
the
the
integrity
over
and
if
you
type
something
it's
not
a
field
name.
So
if
you,
if
you
do
a
property
access,
that's
a
field
name,
it
would
go
to
that.
B
You
know
to
get
that
field
of
the
of
the
record,
and
if
you
type
something
that's
not
a
field
name,
it
would
be
able
to
go
up
to
the
prototype.
So
that
could
explain
how
temporal
would
be
sort
of
okay
to
be
a
a
record
because
it
it
doesn't
have
anything
in
its
domain
over
things
that
are,
you
know,
field
property,
accesses.
C
So
I
didn't
understand
that
about
temporal
and
still
be
the
case
that
the
shallow
object,
you
know
the
actual
instance
is
transparent
and
the
fact
that
it
could.
B
B
C
As
it
should
be,
so
if
co,
if
the
membrane
came
across
a
decimal
instance
where
the
membrane
did
not
already
have
knowledge
of
decimals
specifically,
but
seeing
that
it
was
transitively
immutable
as
decimals
normally
would
be,
I
would
hope
it
wanted
to
just
make
a
copy.
B
C
So
let's
make
the
case
where
you're
passing
it
between
address
spaces.
B
Yeah,
I
I
don't
have
a
solution
for
passing
it
between
address
spaces.
I
was
assuming
that
that
would
be
out
of
scope
for
this,
that
you
would
have
to
do
some
other
kind
of
serialization
thing.
You
would.
C
B
Since
I
feel
like,
if
you're,
if
you
are
using
something
with
private
fields
like
temporal
or
decimal,
you
really
want
to
be
able
to
have
your
internal
representation,
which
is
already
parsed.
And
then
you
want
to
have
a
serialization
which
is
explicitly
designed
and
which
is,
you
know,
a
perfect
bijection
like
it's
a
good
representation
of
what
it's
doing,
but
that
it's
not
not
necessarily
the
same
as
the
representation
in
memory.
C
B
Well,
you
could
have
a
method
like
symbol.serialize
on
decimal
prototype,
or
we
could
say
that
two
string
forms
this
method,
but
two
string
is
way
too
messy.
Probably
for
this
you
would
have.
It
would
just
be
an
explicit
thing:
it
wouldn't
it
wouldn't
just
wouldn't
be
based
on
the
properties,
because
when
you're
using
private
fields
you
you
want
to
be
able
to
evolve
that
and
have
that
not
affect
the
serialization
format.
C
So
there
I
mean:
there's,
there's
the
issue
of
evolving
the
format
to
make
different
implementation,
tradeoffs
that
have
the
same
semantics
and
then
there's
evolving
format
to
express
different
semantics.
B
B
Maybe
decimal
will
sometimes
be
optimized
as
an
ieee
decimal
when
it's
like
in
range
and
otherwise
be
a
variable
length
one,
and
that
that
kind
of
thing
would
be
kind
of
messy
in
memory.
You
wouldn't
want
to
serialize
that
directly.
You
would
want
to
convert
it
to
a
string.
There's
a
there's,
a
unique.
C
So
would
you
accept
the
following
equivalence
that
the
that
all
of
the
information
must
be
available
on
in
a
stereotype
way
through
external
interfaces
such
as
property
access
or
asking
for
a?
C
B
And
yeah,
I
think
that
would
that
would
work
for
for
decimal
for
temporal
temporal
has
has
further
issues
where
it
supports
these
custom
calendars
that
are
just
not
serializable
at
all.
But
if
you
use
temporal
without
a
custom
calendar,
then
it
should.
It
should
be
serializable
in
that.
In
that
strict
sense
of
you
know,
the
the
serialized
thing
could
be
what
you're
comparing
for
for
equality.
B
So
we
could
so
we
could
say
that
if
you're
writing
one
of
these
in
javascript,
you
must
provide
the
serialization
as
a
public
record
field.
But
then
you
can
have
private
record
fields
that
are
calculated
as
a
function
of
this.
But
then,
if
you
have
a
native
implementation
of
it,
it's
allowed
to
sort
of
optimize
that
away
as
long
as
it
provides
observably
equivalent
behavior
is
this
sort
of
what
you're
getting
at.
C
B
They're
they're
interested
in
thinking
about
it
like
they're,
not
ready
to
conclude
that
this
is
the
direction
yet,
but
you
know
niccolo
and
I
are
working
closely
with
them
or
maybe
nikola
is
a
champion
and
the
question
one
question
that
was
raised
by
by
robin
is:
is
it
reasonable
to
split
up
the
which
I
guess
you're
saying?
Yes,
the
notion
of
primitive
versus
object?
Where
object
where
primitives
are
deep,
passed
by
copy
and
objects?
B
Are
you
know
nothing
they're,
they're
self,
they're
they're
not
represented
in
this
this
diagram
because
they
have
all
the
all
the
stuff.
You
know
we're
we're
choosing
a
point
in
between,
but
is
that
too
messy
that
now
javascript
would
have
three
types
of
values,
primitives
objects,
and
this
point
in
between.
C
Yeah
yeah.
That
was
actually
why
I
had
never.
You
know
even
coming
from
e
and
doing
this
distributed
object
system,
metagoric
why
I
have
never
proposed
this
is?
It
is
a
third
concept
and
the
records
and
tuples
before
this
concept
fit
nicely
into
the
existing
concept
of
a
primitive
value,
but
only
if
it's
transitive
once
it's
not
transitive,
then
having
it
be
thought
of
as
a
primitive
value
no
longer
makes
sense.
B
C
B
So
for
the
proxy,
for
the
record
proxies,
did
it
turn
out
that
we
don't
need
a
separate?
You
know
payload
that
as
long
as
you're
doing
the
right
sort
of
copying
when
constructing
the
shadow
target,
it
should
be
enough.
C
C
B
C
A
So
if
we
need
to
copy
the
record
on
tuple
in
a
way
in
order
to
build
the
shuttle
target,
do
we
need
to
allow
creating
proxies
of
the
records,
or
can
we
just
return
a
new
record
containing
proxies
instead
of
the
original
properties.
C
Oh,
I
think
you're
right
just
like
well.
No,
I
don't
know.
C
C
The
membrane
goes
through
whatever
its
distortion
logic
is
to
create
a
mother
record,
which
is
the
shadow
target
for
the
original
record.
Having
created
it,
does
it
gain
anything
by
wrapping
it
in
a
proxy
or
could
it
just
release
the
shadow
target
as
the
representative
on
the
other
side
of
the
member.
C
B
C
So
the
notion
of
a
primitive
that
contains
a
mutable
object
still
really
disturbs
me.
A
notion
of
a
selfless
object
that
contains
a
mutable
object.
Does
not
disturb
me
disturbing
me.
I
grant
is
a
weak
argument.
C
But
it
was,
it
was
the
shift
of
thinking
of
these
things
as
as
identity
free
objects.
That
made
me
comfortable
with
them
having
immutable
leads
and
the
shadow
tar
and
letting
the
shadow
target
be
the
representative
since
it's
since
we're
already
going
through
all
of
the
shadow
target.
Construction
logic
is
consistent
with
immutable
leaves
because
all
the
leaves
would
still
be
on
that
other
side
of
the.
B
Well,
I
don't
think
we
have
to
conclude
on
this
today,
but
more
to
think
about
another
question.
Another
thing
I
wanted
to
raise
is
that
we
heard
concern
from
you
know
the
excess
folks
from
from
peter
who
is,
you
know,
they're
big
users
of
of
success
or
assess
like
system,
and
they
say
that
they
already
get
a
lot
of
benefit
out
of
frozen
objects
and
javascripts,
and
maybe
we
could
do
something
that
more
closely
relates
to
frozen
objects
in
javascript
than
making
up
a
new
thing.
B
C
So
so,
so
I
think
that
you
know
going
back
to
the
to
this
diagram
over
here.
Deep
frozen
does
not
imply
supplements
and
deep
frozen
in
this
diagram
really
meant
transitively
immutable
like
we're,
making
the
the
primordials
incest
the
raw
mobility
that
xs
makes
such
good
use
of
is
all
about
being
transitively
immutable.
C
I
don't
think
that
that
xs
derives
any
additional
benefit
from
being
identity
free.
It's
also
the
case
that
I
don't
think
identity
free
creates
a
problem,
but
I
just
I
just
want
to
make
sure
that
we're
distinguishing
immutability,
you
know
for
purposes
of
roundability
versus
being
identity,
free.
B
Right
so
that
that
seems
consistent
with
their
statement,
and
it
makes
sense
to
me
too,
but
I'm
just
wondering
where
we
should
go
from
here
with
records
and
temples,
because
I'd
like
to
be
able
to
have
something
that
doesn't
add
too
much
complexity
for
everybody
and
presents
some
kind
of
benefit.
You
know
this
is
a
huge
amount
of
work
for
them
to
implement
and
it
doesn't
help
their
users
and
it's
part
of
the
javascript
standard.
A
A
caught
there
you're
talking
about
the
raw
mobility
actually
being
able
to
have
an
immutable
object
that
references
immutable
object
where
the
immutable
part
is
in
rom
and
it
points
into
immutable
memory.
It's
actually
a
a
a
useful
thing
and
I
I
think
it's
a
it's
a
use
case.
They
rely
on.
A
B
C
A
C
Glad
you
raised
read-only
collections
because
that's
been
kicking
around
in
my
mind
since
I
ran
your
proposal,
what
I
would
do
with
the
re
with
the
you
know
the
snapshot
operation
that
we
don't
know
the
the
collection,
the
stable
collections,
which
we
need
a
better
term
for
they're,
currently
called
fixed,
is
given
your
proposal.
I
would
say
that
those
are
shallowly.
C
In
fact,
this
is
what
e
e
did
is
the
snapshot
of
the
snapshot
diverge
and
read
only
view
operations
are
actually
what
I
did
in
e
and
then
e.
I
had
let's
just
take
the
tuple
case.
I
called
them
lists.
I
had
flex
lists
which
are
have
identity
and
are
mutable
by
the
actual
contents
of
the
collection
can
change.
I
had
consoles,
which
was
shallowly
immutable
and
shallowly
identity,
free
to
consoles
compared
only
on
content,
and
then
I
had
a
read-only
view
which
had
identity.
C
A
B
It
would,
it
would
probably
add
some
implementation
complexity
to
add
a
path
to
interning
those
read-only
collections,
but
I
think
it
would
have
real
user
benefit.
I
mean
people
asked
people
mentioned
on
twitter
that
they
would
really
want
to.
Have
you
know,
maps
as
record
keys
or
one
person
did.
I
didn't
really
understand
his
use
case
completely.
B
But
you
know,
there's
maps
are
maps
are
ordered,
so
comparison
wouldn't
work
very
well
for
them.
We
might.
We
might
want
to
make
some
kind
of
well.
I
don't
even
know
how
you
would
make
an
unordered
map
because
you
can't
sort
the
entries,
but
you
can
make.
C
So
you
know,
just
like
the
current
map
and
set
in
javascript
is
indexed
with
an
equivalence
class.
That's
not
our
most
precise
form.
It's
indexed
by
same
value,
zero,
rather
than
being
indexed
by
object.
Is
you
can,
if
you
have
a
well-defined
equivalence
class,
that's
less
precise,
that
that
holds
more
objects
to
be
in
the
signal
to
be
equivalent
to
each
other.
Even
though
they're
not
the
same
object.
C
C
The
passable
collection
will
consider
them
to
be
equivalent
for
purposes
of
index.
Lookup.
B
C
Yeah
you
would
need
to
introduce,
I
don't
I
don't
want
to
neither
triple
equals.
Nor
same
value
is
one
that
I
would
want
to
make
any
less
precise.
C
It's
actually
same
value
made
conceivably,
that's
interesting,
that's
interesting
same
value
is
definitely
one
that
I
don't
want
to
make
any
less
precise
same
value:
zero,
wow!
That's
really
bizarre!.
B
Can
we
can
we
see
if
we
could
bring
the
excess
people
into
the
conversation
with
us
about
records
and
tuples,
because
sure
you
know
we're
having
an
email
thread
but
with
you
know
me
and
nicolo,
and
the
champion
group
and
them,
and
I
kind
of
feel
like
we're
talking
past
each
other,
and
I
feel,
like
your.
Your
analysis
could
really
help
us
understand
things.
C
Yeah
yeah,
yes,
model
folk
would
be
wonderful
to
have
in
this
conversation
the.
Let
me
tell
you
the
scheduling
constraint
on
the
modern
little
folk
is
peter's
here
in
palo
alto,
so
he's
you
know,
you
know
meetable
during
the
same
times
that
most
of
the
rest
of
us
are
patrick,
is
I
think
in
france,
but
definitely
in
europe.
So
when
we've
met
with
both
of
them,
we've
generally
had
meetings
at
eight
o'clock
in
the
morning
pacific
time
we
could
certainly
do
that.
B
C
Okay,
yeah
adopting
a
a
europe-friendly
time
zone
for
a
lot
I
mean
it
was
a
europe-friendly
time
slot
for
a
lot
of
these
meetings,
I
think,
makes
a
lot
of
sense.
B
C
Oh,
I
did
not
look
at
the
decorator
thing
at
all,
so
if
you're
happy
to
start
cold,
go
for.
A
B
And
there's
there's
a
lot
of
people
here,
who's
whose
opinion
I
would
be
happy
to
have
about
this
new
decorator
proposal.
So
I
mean
you
know
everybody
so
so
yeah
chip
link
to
it.
I
guess
I
should
screen
share
so
that
I
can
point
that
to
different.
Oh,
no
chip
link,
two
different
one.
Let.
C
C
B
And
the
core
concept
is
that
decorators
wrap
a
a
class
element
and
annotations
they
put
some
metadata
on
it.
When
you
wrap
a
piece
of
storage
like
a
field,
it
becomes
a
getter
setter
pair
for
accessing
that
storage
and
that's
useful
for
observation.
But
if
you
just
annotate
a
field,
it
just
adds
the
metadata
it
doesn't.
It
doesn't
wrap
it
in
that
way.
B
C
B
That
too,
that
would
be
a
great
idea
yeah.
So
I
have
these
things
in
terms
of
d
triggering,
so
these
sugar
rings
are
kind
of
rough,
but
the
idea
is,
you
could
decorate
public
and
private
things.
So
there's
the
decorator
gets
past
this
this
function,
but
it
doesn't
get
past
the
class.
So
although
this
desugaring
is
phrased
in
terms
of
mutations,
it
can
actually
be
thought
of
as
running
while
the
class
declaration
is
is
executing
right,
good.
C
So
if,
during
that
execution,
it
does
happen
to
have
access
to
the
class
and
it
looks
for
the
binding,
it
won't
see
a
binding
because
you're
not
mutating
the
binding
you're
calculating
the
initiative.
B
So
then,
for
you
know
you
could
have
a
class
decorator
which
decorates
the
class
and
that
you
know
similarly
just
sort
of
wraps
the
class
in
a
function,
and
you
can
use
this
pattern
of
you
know
this
sort
of
currying
pattern
make
like
a
decorator
factory,
so
the
decorators
can
take
arguments.
C
So
I
thought
that
the
whole
notion
of
decorators
as
functions
that
run
at
one
time,
was
the
thing
that
people
were
objecting
to
on
initialization
time
overhead
grounds.
B
The
thing
that
people
were
objecting
to
was,
I
think,
decorators
being
dynamic
in
their
effect
on
class
shape.
So
all
the
previous
decorators
proposals
it
depended,
which
decorator
was
running
different
decorators,
would
change
the
class
shape
in
different
ways.
In
this
proposal,
the
class
shape
has
changed
in
the
exact
same
way
each
time,
but
further.
If
you
just
have
something
to
do
with
metadata,
there
should
be
a
declarative
way
to
do
it.
That's
another
sort
of
invariant
that
was
raised
and
annotations
do
that
they
you
know.
Of
course
they
evaluate
the
object
literal.
B
C
Okay,
so
let
me
make
sure
I
understand
the
previous
point.
The
there
was
an
overhead
issue
they
were
concerned
about,
but
it
was
not
the
fact
that
the
decorators
have
to
be
executed
at
initialized
time.
It's
the
fact
that,
because
they
changed
the
shape,
they
preclude
optimizations.
C
B
You
know
template
for
making
the
constructor
itself
the
the
thing
about
this
boilerplate
optimization
is,
it's
also
broken
by
computed
property
keys,
but
the
hope
is
that
we
sort
of
don't
make
it
any
worse.
You
can
still
apply
sort
of
in
practice,
quote-unquote
much
of
the
time
so
that
that's
one
of
the
pieces
of
motivation
here.
B
Oh,
the
reason
is
because
you
have
to
do
some
initial
execution
of
the
code.
The
it
turns
out.
The
interpreter
performance
is
really
key
to
making
javascript
fast
in
real
life.
So,
like
five
or
ten
years
ago,
everybody
was
optimistic
about
these
super
advanced
jits,
making
all
these
optimistic
assumptions
being
the
key
to
performance.
B
But
what
it
turned
out
was
a
lot
of
these
fancy.
Optimizations
just
didn't
provide
net
performance
win.
You
have
to
run
the
code
a
number
of
times
for
the
optimizations
to
pay
for
themselves.
That's
why
people
make
these
multi-tier
optimizing
compilers,
but
also
most
javascript
code.
Just
runs
just
runs
once
so.
When
you
have
a
class
definition,
the
class
declaration
is
probably
going
to
just
run
once
and
it
won't
benefit
from
any
of
those
optimizations,
it's
better
to
use
a
very
low
tier.
B
B
B
So
the
other
thing
is
that
decorators
can
add
annotations,
so
decorators
are
actually
passed
with
two
arguments.
One
argument
is
the
thing
they're
wrapping
and
the
other
argument
is
the
context
object
which
provides
more
information
that
I'll
show
examples
of
using
it
below.
B
Maybe
it's
an
ugly
api,
but
each
each
decorator
gets
past
a
fresh
context,
object
and
if
you
add
on
an
annotations
object
to
that,
then
that
gets
ultimately
added
to
the
annotations
for
the
for
the
class
element,
so
that
this
is
something
that
would
be
fine
to
bike
shed
about,
because
mutating
is
is
ugly,
but
at
the
same
time
it's
nice
that
the
return
value,
the
decorator
is
just
simply
the
new
thing
that
is
the
result
of
wrapping.
C
The
the
line
that's
currently
at
the
top
of
the
screen,
now
it's
more
in
the
middle
of
the
screen
c,
open
square
bracket,
symbol,
dot,
annotations,
close
square
bracket,
dot,
prototype
methods.
B
Yeah,
so
this
is
also
a
great
thing
to
bike
shed
about,
but
there
would
be
some
object.
So
there
was
this
reflect
metadata
proposal
by
ron
buckton
that
had
a
a
whole
bunch
of
methods
for
metadata
that
was
held
in
internal
slots.
B
C
B
B
But
that
might
conflict
with
some
existing
thing.
I
don't
know.
B
B
B
I
just
left
that
line
out
and
you
can
see
that
the
the
logic
here
is
that
it
sets
the
annotations
by
looking
at
the
annotations
and
defaulting
to
you
know
an
empty
object
and
it
just
splats
these
together,
one,
the
one
on
the
outside
would
override
the
one
on
the
inside.
B
So
one
common
use
case
for
decorators
is
to
make
an
observed
property,
so
you
have
a
property,
but
you
want
it
to
be
actually
an
accessor
with
backing
storage
and
at
first.
I
wasn't
very
convinced
that
this
was
such
a
special
pattern.
But
after
talking
to
people
for
a
while,
I
think
this
is
what
logically
makes
sense
to
do.
When
you're
wrapping
storage,
when
you're
wrapping
storage,
you
want
to
make
it
into
a
getter
setter
with
a
special
path
to
initialize
it.
B
B
B
C
B
C
A
B
And
the
cool
thing
about
this
is
sure
that
the
property
key
is
passed
to
the
decorator,
but
this
actually
works
just
fine
for
tracking
private
fields,
with
just
no
changes
as
long
as
you
don't
depend
as
long
as
you
handle
a
case
where
the
kind
is
missing,
because
no,
no,
not
the
kind,
the
name,
if
you
as
long
as
you
handle
the
case
where
the
name
is
missing.
This
works
just
fine
on
on
private
fields.
B
B
C
Yeah
yeah,
that
makes
sense.
I
think
this
proposal
would
mean
the
same
thing
if
you
just
erased
the
those
two
lines
from
the
distributor,
correct.
C
But
you
don't
need
access
to
the
private
field
because
all
accesses
are
getting
turned
into
calls
to
to
the
get
and
set
you're
providing.
B
A
B
Tract
is
defined
here,
track
takes
the
get
and
set;
actually
it
should
return
initialize.
I
have
it
not
return
initialize
here,
but
imagine
initialize
being
a
new
identity
function,
it
reuses
the
get
and
it
wraps
the
set
that
it
gets
where
it
compare
for
it
calls
get
again
and
it
checks
whether
get
will
equal
the
value
and
then
it
calls
the
underlying
set
if
needed,
and
it
calls
a
re-render.
B
A
C
B
There
are
protocols
where
we
could
make
that
work
like
we
could
call
get
sort
of
with
the
new
with
the
underlying
value
and
then
get
would
be
allowed
to
make
distortions
on
it,
and
we
could
call
set
with
the
value
that's
being
set,
and
then
the
decorator
could
do
distortions
on
it,
but
it
gets
tricky
because
then
sometimes
you
want
to
do
things
like
like
in
this
case,
where
we
call
the
get
within
the
set
and
you
might,
you
might
actually
want
to
leak
the
get
and
set
methods
callbacks,
as
in
the
next
example,.
B
A
B
B
B
So
private
fields,
a
common
thing
is,
you
might
want
to
grant
access
to
a
private
field
or
method
to
something
else,
and
so
this
private
key
library
lets.
You
use
this
method.
The
show
method
to
expose
a
private,
a
private
field
to
this
key,
which
then
can
be
used
as
a
sort
of
capability
to
access
it
and
that
works.
You
know.
C
B
Yeah,
that's
right.
I.
A
B
A
And
the
result
of
that
is
used
as
the
decorator
right:
okay,
yeah
yeah,
so
it's
like
syntax
notwithstanding,
who
knows
if
parentheses
will
be
valid
there
or
not,
but
just
this
is
this
is
like
key
as
a
normal
object.
Look
up
do
a
get
of
show
from
that
object
and
then
the
result
of
that
is
your
decorator.
B
Yeah
in
this
proposal
we're
sticking
to
the
syntax
of
stage
q,
decorators,
so
parentheses
would
be
valid
there.
They
would
be
your
escape
hatch
because
you
can't
write
arbitrary
expressions.
However,
if
you
want
to
do
a
method,
call,
it's
important
to
might
be
important
to
not
have
parentheses.
B
So
you
know
there
are
other
ways
that
we
could
broaden
the
scope
of
private
names,
but
I
thought
this
example
was
cool,
partly
because
it
just
fell
out
of
the
other
semantics
that
we
were
discussing.
I
was
previously
thinking
we
would
have
to
create
a
kind
of
private
name
object
and
pass
it
as
a
parameter
in
the
name
field,
but
I
think
we
can
do
without
that
at
first.
B
It
got
complicated,
but
we
actually
kind
of
solved
it.
We
got
agreement
on
on
a
lot
of
details
about
it
and
I
still
think
it
would
be
valuable
to
to
pick
up
again
to
have
references
like
first
class
references
to
private
names,
but
for
the
for
the
more
limited
case
of
having
a
decorator
to
decorate
a
field
to
to
grant
access
to
a
particular
thing,
which
I
think
is
a
useful
particular
case.
B
You
can
use
this
pattern
where
you
know
show,
takes,
get
and
set
sets
its
private
fields
to
that,
and
then
it
has
git
and
set
methods
that
call
it
and
it
de-triggers
to
something
like
this.
So
this
is
using
an
even
worse
pattern.
Where,
because
we
don't
have
static
blocks,
we
could
use
a
static.
B
So
I'm
I'm
kind
of
assuming
that
if
you
don't
return
an
initialize
function,
then
the
identity
function
will
be
used,
but
that's
not
present
in
this
degree,
so
the
distribution
doesn't
work.
A
What
is,
if
you
go
back,
two
blocks
up.
What
is
the
definition
of
key
okay.
B
So
I
mean
we
had
we
had
the
discussion
in
this
meeting
about
whether
it's
okay
to
allow
access
for
for
decorators
to
private
fields,
and
we
came
to
the
conclusion
that
it's
okay
as
long
as
you're,
directly
decorating
that
private
element
right.
This
version
of
the
proposal
sort
of
meets.
That
requirement.
Where.
A
B
Creating
that
particular
private
element
and
you're
just
getting
access
to
that
particular
thing
that
you're
decorating.
B
So
finally,
this
deprecated
version
this
decor
deprecated
decorator.
I
want
to
show
an
example
of
dispatching
off
the
kind,
because
you
know
the
context
argument.
It's
a
little
bit
ugly
that
there
has
to
be
a
second
argument,
but
I
really
do
think
it's
useful.
For
example,
when
you
have
a
field
and
you
want
to
deprecate
it,
you
need
to
wrap
the
get
and
set
things,
whereas
if
you
have
a
method
or
get
a
resetter
and
you
want
to
deprecate
it,
you
just
wrap
the
function.
B
Now
a
late
edition
can.
B
B
You
know
there
was
this
whole
discussion
around
coalescing
with
decorators,
but
I
feel
like
coalescing
is
really
it's
mostly
a
thing,
that's
necessary
for
when
you're
converting
a
field
into
a
ghetto
setter
pair,
and
so
now
we're
just
representing
that
directly.
Okay,.
B
So
now
this
late
edition
from
jordan
harban
was
that
we
make
it
so
there's
a
way
when
you
have
a
method
and
you
decorate
it
so
that
there's
a
there's,
a
callback,
that's
called
when
the
object
is
getting
created.
B
So
you
put
this
init
contextual
keyword
here,
there's
an
unfortunate
known
line
terminator
here
right
there,
and
so
it
gets
the
method
and
it
returns
both
a
method
and
an
initialized
callback.
So
in
this
case
it
registered
the
on
decorator
registers
and
event
handler.
C
Look:
okay,
put
back
on
the
screen
the
piece
of
code
that
uses
the
on
decorator;
that's
above
this
one;
okay
right!
Please!
Yes,
good!
Just
stay
there
for
a.
A
A
B
B
C
C
A
B
A
C
B
B
Right,
the
object
is
the
receiver,
the
event
that's
emitted,
so,
okay,
so
those
in
the
dom
are
not
handled.
They
don't
directly
call
calls
method
calls,
but
they
call
the
there's
this
event
target
concept
and
the
object,
and
you
can
listen
to
the
events
on
yourself
or
you
could
also
register
listeners
that
are
not
part
of
the
class.
This
is
just
if
you
wanted
to
do
one
pattern
so,
but
the
important
thing
here
is
that
the
fact
that
there
is
an
initialization
action
is
indicated
syntactically
with
this
init
keyword.
B
C
C
I
see
honestly,
I
see
I
see
because.
B
C
B
Means
the
kind
the
name
which
is
the
property
key
is
static
and
you
can
add
annotations
to
it.
C
C
B
I
would
be
fine
with
leaving
init
decorators
for
or
knit
methods
for
a
follow-on
proposal,
but
I
want
to
show
that
they
work
within
this
broader
framework,
so
jordan
felt
that
it's
very
important
to
have
a
bound
decorator
and
bound
decorators
fit
into
this
framework.
As
long
as
we
have
a
place
in
the
constructor
to
run
a
code,
snippet
jordan
considers
this
kind
of
bound
decorator
to
be
sort
of
one
of
the
primary
use
cases
of
decorators.
So
that's
why
I
included
in
it
in
this
draft,
but
I'm
still
open
to
reconsidering
it.
B
C
So
I
don't
understand
that
so
so
the
goal
makes
sense
from
the
example
in
the
middle
of
the
screen.
I
do
not
understand
how
this
example
brings
about
that
goal.
B
B
Has
become
popular
where
you
do,
you
know,
method
equals
and
then
you
just
use
an
arrow
function.
C
Okay:
okay,
okay,
okay,
I
I
understand
what
it's
doing.
The
problem
is
that
this
has
the
overhead
of
creating
a
bound
method
per
method.
I
mean
about
method.
Allocation,
creates
an
allocation
per
method
per
instance
and
there,
and
so
it's
getting
all
the
benefits
of
the
object
disclosure
pattern
by
paying
the
prohibitive
cost
of
the
object
disclosure
pattern,
which
is
exactly
the
reason
why
people
you
know
why
we
could
not
get
people
to
use
the
object's
closure
pattern
is
that
is
that
in
end
times,
m
allocation.
C
C
B
In
a
previous
version
of
this
document,
where
I
had
it
instead
of
unit
methods,
I
had
trap
methods
that
would
convert
the
method
into
a
get
or
sitter
pair.
With
a
with
an
underlying
storage,
I
had
that
it
would
create
this
thing
on
the
first
use
and
it
would
cache
it
in
the
storage
or
maybe
we
could
not
cache
it
either
way
anyway,
jordan
didn't
like
this.
He
thought
that
immediate
that
wasn't
testable.
B
A
B
If
we
didn't
require
a
new
contextual
keyword,
then
we
would
have
to
add
the
space
for
an
initialization
action
for
every
decorated
method.
But
it's
a
goal
of
this
proposal
that
the
the
overhead
of
doing
these
extra
calls
for
potential
initialization
actions
only
be
incurred
at
the
decorator
usage
sites,
where
it's
actually
requested
by
the
user.
B
We
could
have
it
be
that
the
code
would
call
into
sort
of
an
undefined
local
variable
that
would
then
get
filled
in
by
the
decorator.
Would
just
do
it.
Do
a
function
call
there,
but
we
would
incur.
These
function,
calls
for
every
single
decorated
method.
C
B
B
This
is
basically
the
core
thing
that
made
the
previous
stage
two
decorators
invalid,
like
unacceptable
for
va
and
the
static
decorators
was
one
attempt
to
solve
it.
This
is
another
attempt
to
solve
it
by
saying
that
decorators
always
do
just
one
just
one
particular
thing.
A
C
A
Have
anything
more
to
add
on
that
right
now,
but
it
does
feel
like,
like
that's
the
that's
the
weakest
aspect
of
what
we're
looking
at.
B
So
yeah
I
would
personally,
I
would
be
happy
to
leave
this
for
a
follow-on
proposal,
for
you
know
future
consideration.
I
don't
see,
I
don't
think
it
needs
to
be
in
the
decorator
mvp,
but
yeah.
We
have
this
sort
of
contradiction
among
goals
where
typescript
wants
decorators
to
be
transfiliable
in
a
single
file
context.
B
A
So
if
we,
if
we
look
at
the
at
the
d,
sugared
version,
the.
C
A
On
maybe
yeah,
so
I.
A
So
va
having
established
the
shape
of
a
of
a
class
based
on
based
on
syntax
for
instantiation,
the
constructor
is
still
going
to
run
and
the
constructor
itself
can
do
the
very
same
things
that
we're
talking
about
decorator
initialization,
wanting
to
do
like,
by
definition,
we're
looking
at
we're.
Looking
at
it
right
here
in
the
description.
B
Yeah,
that's
right,
so
we
could
do
an
extra
function.
Call
on
every
single
method.
That's
decorated
in
the
initializer
for
the
class.
That
would
be
kind
of
a
unfortunate
because
another
one
of
the
its
constraints
is
that
there
should
not
be
runtime.
Overheading
occurred
for
the
parts
of
decorators
that
you're
not
trying
to
use,
and
my
my
analysis
is
that
most
use
cases
for
method
decorators
are
not
trying
to
add
these
initialization
actions.
B
B
C
B
A
A
A
B
Right
exactly
so,
that's
the
motivation
for
the
init,
contextual
keyword,
which
I
agree
is
unfortunate.
So
I
guess
we're
over
time
like
I
can
keep
going,
but
maybe,
but
this
really
just
gets
into
details
that
I've
actually
been
describing
here
I
say
like
look.
B
The
id
decorator
is
not
the
id
decorator
because
it
changes
the
semantics
of
fields
as
being
backed
by
private
field,
which
is
totally
observable,
and
that's
just
something
that
we're
buying
into
because
we're
saying
when
you
wrap
something
that's
this
is
how
you
reify
it,
and
it
has
these
these
observable
effects.
So.
C
C
B
B
This
was
decided
at
the
2016,
I
think,
may
munich
tc39
meeting
that's
all
we
already
are
seeing
sort
of
the
fallout
of
that
in
because
the
static
field
initializers
can
see
the
class,
so
the
class
is
already
out
of
tdz
there,
and
so
defensive
classes
become
difficult
with
that
decision
that
we
made
in
2016,
but.
C
There
was
there
was
a
recent
discussion
about
the
class
name
being
found
inside
the
class
versus
the
class
name
being
found
outside
the
class.
B
Well,
I'm
not
changing
it's
not
changing
that,
so
we
could
make
a
second
callback,
but
right
now,
in
this
proposal
the
class
decorator
callback
is
called
before
the
static
fields
are
added.
You
know,
in
the
stage
2
decorators
proposal,
there
were
several
different
callbacks.
There
were
all
these
different
stages,
and
this
was
very
confusing
to
people.
They
were
all
these
sort
of
finalizers
or
whatever
they
were
called
finishers
and
people
found
all
these
different
callbacks
really
confusing.
So
this
proposal
collapses
it
into
there's
just
one
time.
The
decorators
run.
B
The
time
is
sort
of
during
class
evaluation,
and
I
guess
different
decorators
run
at
different
times.
You
know
the
fields,
the
fields
and
methods
run
and
and
the
plastic
order
runs,
and
then
the
static
fields
are
evaluated
which
includes
evaluating
those
static
field
decorators.
B
So
we
could.
We
could
somehow
add
a
callback
that
you
could
register
in
the
class
decorator
to
freeze
the
constructor,
but
I
think
that
would
add
a
lot
of
complexity
to
the
proposal,
but
I
I
also
feel
like
the
most
important
part
of
defensive
classes.
Is
the
prototype
being
frozen
and
the
instance
is
being
frozen
and
the
instances
can
be
frozen?
B
B
So
yeah
also
this
would
allow
function,
decorations
and
annotations,
but
if,
if
you
decorate
or
annotate
a
function,
it's
no
longer
able
to
be
hoisted
because
code
has
to
execute
for
the
function
declaration
to
evaluate
so
it
would
just
be.
It
would
be
like
a
class.
It
would
be
in
tdz
until
you
reach
that.
C
A
B
B
Parameter
decorators,
you
could
have
a
parameter
decorator.
Fundamentally,
it
returns
a
function
that
goes
from
the
argument
and
returns
a
new
value
of
the
argument,
and
it
could
actually
be
called
with
the
this
value.
If
it's
a
method
of
the
enclosing
thing-
and
it
could
also,
they
can
also
add
annotations.
C
Okay,
so
in
particular
you
could
have
a
input
validation
check
like
if
the,
if
this
per,
if
the
argument
that
would
be
bound
to
this
parameter,
is
not
positive.
A
positive
number
threat.
B
Yes,
exactly
exactly
or
casting,
you
could
also
do
casting
through
this,
but.
B
Yeah,
that's
all,
and
it
just
lets
you
put
annotations
on
and
it
will
apply
to
the
right
parameter.
So
I
think
typescript
parameter
decorators
were
kind
of
more
complicated
where
you'd
get
the
parameter
index
and
then
you'd
be
responsible
for
wrapping
the
whole
function.
Based
on
that
and
that
that's
me
always
seemed
kind
of
like
a
layering
violation
or
something
okay.
C
A
B
Yeah,
that's
that's
kind
of
further
down
here,
but
before
value
decorators,
here's
sort
of
the
craziest
one.
We
could
have
a
let
decorator
where,
when
you
decorate
a
mutable
variable,
it
converts
it
into
a
getter
setter
pair
just
like
fields
and
when
then,
when
you
write
to
the
variable,
it
we'll
call
the
the
setter.
So
the
reason.
B
Be
okay
is
that
it's
very
statically
analyzable
when
you
see
a
decorated,
let
you
know
that
it's
that
it
can't
leak
out
of
sloppy
motif
or
anything
like
that,
but
it
it
is
kind
of
it
is
kind
of
crazy,
but
I
think
I
thought
it
might
be
useful
for
stuff
like
react
hooks
where
they
want
to
where
they
use
these
local
set
functions.
B
C
Better
syntax
yeah-
this
was
also
a
component
of
our
guard's
proposal-
is
that
you
could
have
a
guarded,
let
variable
where
the
guard
would
do
input,
validation,
any
assignment
to
the
variable.
B
So
I'm
really
I'm
really
interested
in
this
guard
proposal.
I
kind
of
feel
like
there's
two
concepts
to
pursue,
maybe
separately,
one
is
a
one,
is
a
trap
that
works
on
reads
and
rights
and
is
allowed
to
transform
the
value
and
the
other
is
a
guard
where
you're
only
checking
a
property
of
the
value
and
your
choices
are
to
throw
or
not
or
not.
Throw
you
see
that
kind
of
category
distinction.
C
C
That's
correct,
that's
correct,
and
that
way
the
thing
is
variables
are
read
tremendously
more
often
than
they're
written.
So
if
you
can
intervene
only
on
the
assignment
and
the
initialization
and
by
the
way
you
should
have
a
separate
initialize,
just
like
you
had
for
fields,
but
if
you
can
initiate
you
can
intervene
only
on
the
initialization
assignment
and
leave
the
reads
unmodified.
B
B
And
yeah:
that's
that's
the
that's
the
proposal
and
more
about
the
motivation
here,
but
do
you
think
I
was
thinking
that
if,
if
this
seems
reasonable,
then
we
would
go
into
like
a
six-month?
B
You
know
prototyping
period
to
validate
it
and
maybe
after
that
propose
advancement
is
this?
Does
this
seem
like
a
reasonable
direction
to
all
of
you.
C
Yes,
I
think
it's
worth
investigating,
I'm
you
know
I
have
I'm
sort
of
torn
in
the
normal
way
of
being
torn
on
these
things,
which
is,
on
the
one
hand,
there's
all
sorts
of
enablers
from
my
favorite
features
that
I
would
like
to
have
in
there.
But
on
the
other
hand,
I
would
also
think
I'm
almost
reacting
god.
I
wish
it
was
simpler
than
this.
So
so
yeah,
it's
the
normal
tension.