►
From YouTube: Readonly Collections for JS
Description
Presented at TC39 Oct 2019. https://github.com/tc39/proposal-readonly-collections
Achieved stage 1 status.
Slides:
https://github.com/tc39/agendas/blob/master/2019/10.readonly-collections-as-recorded.pdf
Currently, JavaScript collections are unconditionally mutable. We believe many use cases could benefit from separating the ability to query a collection from the ability to mutate it. We’ve seen repeated calls for such support. To minimize the cognitive load of new API, we propose the addition of only three new methods to all collections and the addition of new collection classes whose APIs are only a subset of the existing collection abstractions.
A
A
So
there's
the
principle
of
least
Authority
only
give
things
the
ability
to
cause
changes
that
they
need
to
have
to
do
their
job,
which
prevents
all
sorts
of
accidental
or
malicious,
exploits
defensive
programming,
functional
programming
and
the
new
one
that
we
became
aware
of
through
TC
53,
and
the
model
folk
is
that
things
which
are
not
mutable
can
be
put
in
ROM
and
right
now.
Moddable
and
the
TC
53
efforts
are
actually
paying
the
costs
of
not
being
able
to
put
in
rom
in
a
cheap
way.
A
So
just
a
quick
historical
sequence
here,
which
is
what
I
got
involved
in
the
committee.
It
was
the
es
3
days.
Everything
was
pervasively
mutable
everywhere
it
was
really
impossible
to
do
any
kind
of
defensive
programming,
so
es
5
introduced,
object,
dot,
freeze
which
enables
you
to
tamper
proof,
an
API
surface
by
by
locking
down
public
properties,
and
that
was
a
tremendous
progress.
A
A
Everything
I'm
saying
applies
to
all,
or
at
least
most
of
the
collections
we
have
but
I'm
going
to
do
this
part
of
the
talk
in
terms
of
one
particular
example:
collection,
abstraction,
which
is
the
map.
So
the
thing
that
we
call
map
has
both
query
and
update
mutations
and
with
a
map
you
can
use
these
these
update
operations
to
cause
mutations.
So
you
can
both
cause
mutations
and
observe
the
mutations
that
you
caused
with
a
map.
A
A
Operations
are
stable,
that,
whatever
you
see
now
through
those
query
operations
on
a
given
fixed
map,
you'll
always
see
for
the
same
query
on
the
same
fixed
map
and
then
a
read-only
map
where
the
query
methods
on
fixed
map
and
read-only
map
and
map
or
all
the
same
query,
methods,
read-only
map
and
curt
and
fixed
map,
in
fact,
have
the
same
API.
Just
the
query
methods.
But
the
guarantees
are
different
on
a
read-only
map.
You
can't
the
query.
Operations
might
show
you
different
values
at
different
times,
so
that
you
can
observe
mutation.
A
But
if
I
give
you
a
read-only
map,
you
might
be
able
to
observe
mutations
that
I
caused.
But
by
giving
you
a
read-only
map,
you
can't
cause
those
mutations.
You
can
only
observe
them
and
hence
hence
the
only
in
the
name,
and
then
there
be
three
Universal
methods
where
we're
all
collections
would
would
have
all
three
of
these
methods.
A
first
message
is
snapshot.
A
We're
a
snapshot
always
gives
you
back
a
map
that
obeys
the
fixed
map
contract.
So
if
you
do
it
to
a
fixed
map,
the
fixed
map
already
obeys
the
fix
map
contracts.
What
just
returns
itself,
if
you
do
it
to
a
map
or
a
read-only
map,
then
it
makes
a
snapshot
of
the
current
state
of
those
maps
and
gives
you
back
a
new
fixed
map
with
that
snapshot.
A
A
A
A
And
then
read-only
view
gives
you
back
a
map
that
satisfies
the
read-only
view,
contract
and
I,
that
this
is
the
one
where
it's
important
to
speak.
Precisely.
It
doesn't
give
you
back
an
instance
of
read-only
map.
It
gives
you
Matt
back
a
map
that
satisfies
the
read-only
view,
contract
and
the
contract.
Is
that.
A
That
if
you
say
to
some
map
read-only
view
and
you
get
back
a
read-only
view
of
it,
then
whatever
the
query
operations
would
show
to
be
the
state
of
the
original
map
that
you
said,
the
read-only
view
on
the
the
query.
Operations
on
the
read-only
view
continue
to
give
you
back
the
same
values.
So
if
you
have
a
read-only
map,
it
can
return
the
same
map.
A
If
you
can't
have
a
regular
map,
it
gives
you
back
a
read-only
view
that
tracks
the
continuing
evolution
of
the
map
you
started
with
and
a
the
read-only
view
of
a
fixed
map
is
just
the
fixed
map
itself.
So
it's
not
an
instance
of
it's
not
a
direct
instance
of
read-only
map,
but
it
obeys
the
read-only
map
contract.
A
So
these
three
operations
would
clearly
apply
to
both
map
and
set
weak
map
and
weeks.
That
are
an
interesting
case.
Read-Only
view
clearly
applies
and
is
meaningful
and
can
be
implemented
with
the
shin.
Also
by
the
way,
all
these
operations
would
be
implemented
as
with
the
shim
on
map
and
set.
What's
a
little
bit
surprising
is
to
consider
snapshot
and
diverge
on
weak
map
in
a
weak
set.
A
A
Typed,
arrays
I
think
all
of
these
just
applied
directly
with
no
qualification.
Likewise,
with
the
raid
buffers
and
array
buffer
is
the
one
whose
absence
really
hurt
is
really
currently
hurting
the
model
and
TC
53
efforts.
You
really
want
to
be
able
to
at
Build
time
calculate
the
contents
of
an
array
buffer,
then
create
a
fixed
array
buffer,
an
immutable
one
so
that
it
can
be
put
into
ROM
and
then
cut
Iram
with
the
entire
array
buffer,
just
in
ROM,
with
no
bookkeeping
to
to
emulate
the
ability
to
mutate.
A
The
array
buffer,
there's
some
odd
balls,
which
I
don't
know
what
to
do
with
I,
haven't
really
thought
deeply
about,
certainly
like
feedback
during
stage.
One
shared
array
buffers
for
which
probably
these
things
are
not
meaningful
or
they're
meaningful
in
a
limited
manner.
Normal
raised
I'm,
proposing
that
we
do
not
try
to
extend
this
scheme
to
normal
arrays,
because
normal
arrays
aren't
really
a
collection
in
a
coherent
manner.
They
can
have
holes
in
it.
A
Behavior
they're,
not
really
recognized
by
the
language
as
a
collection
type
and
then
finally,
there's
objects
themselves,
which
are
often
thought
about,
as
if
they're,
a
collection
of
properties
or
collection
of
property
to
to
property
value,
mappings
and
I
think
that
one
could
consider
reflective
views
of
an
object
to
be
a
collection
so
that
you
know
things
like
from
entries.
It's
giving
you
back
a
collection
that
record
that
represents
in
collection,
API.
In
that
case,
an
iterator
elbow
in
a
rate
represents
a
view
of
the
object,
but
the
object
themselves
should
not.
A
Some
issues
to
consider
that
I'm
proposing
not
be
included
in
the
proposal
but
I'm
happy
to
have
them,
be
questions
to
examine
during
stage
one
is.
This
proposal
does
not
include
any
means
to
fix
in
a
collection
in
place,
so,
like
object,
dot
freeze
for
properties
fixes
the
properties
in
place.
It
doesn't
make
a
new
object.
That's
like
the
old
object
with
fixed
properties.
It
just
takes
the
properties
that
it
has
in
fixed
in
place.
One
could
imagine
a
similar
operation
for
a
mutable
map.
The
reason
I
think
it
would
be
a
bad
idea.
A
One
of
the
reasons
I
think
that
bad
idea
is
that
you
don't
get
API
clarity.
If
you
do
that,
the
the
immutable
map
continues
to
inherit
format
continues
to
inherit
all
the
update
operations
and
the
update
operations
would
now
just
throw
errors
and
I
think
that
by
making
these
things,
essentially,
three
distinct
class
like
abstractions,
where
the
other
two
only
have
the
query
operations.
The
API
doesn't
suggest
that
you
that
things
will
work
that
don't
it
also
avoids
the
issue
of
whether
your
mutable
or
not
being
a
stateful
thing
as
opposed
to
what
what
object?