►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
But
it
seems
those
questions
are
cleared
out
already
by
daniel's
work
and
daniel
already
like
kicked
off
most
of
these
those.
This
work
solving
some
questions
that
we've
had
and
at
some
point
karidi
had
some
syncs
as
well
with
daniel,
and
it
seems
like
symbols
as
weak
map.
Keys
are
the
way
to
go,
and
probably
a
easiest
path
compared
to
the
object,
create
identity,
shareable
shareable
identity
is,
is.
A
There
a
leo
is
there
a
so
so,
first
of
all,
the
the
object
of
shareable
identity
that
kurdi
was
proposing
was
a
frozen
empty
object
with
no
prototype
and
in
the
semantics
of
javascript,
a
frozen
empty
object
with
no
prototype
has
no
realm
specific
semantics.
It's
completely
immutable
context-free
identity.
A
B
I
from
minus,
sending
it's
like
a
more
simple
implementation
process
and
actually
saying
what
means
to
be
generating
these
values,
but
I
this
is
this
parts
from
assumption.
I
I
believe
daniel
will
have
better
context
to
to
talk
about
this.
I
also
think
when
we
talk
about
these
objects
and
the
creation
process
of
these
objects.
B
C
So
I
I
hear
mark's
aesthetic
preference
I
right
now.
I
see
this
mostly
as
a
it's
not
so
hard
to
implement
either
way.
I
think
if
we
say
an
object,
if
we
want
to
make
a
new
way
to
vent
an
object
which
has
no
prototype
or
no
prototype
and
it's
frozen,
it
has
no
properties,
then
we
could
mark
it
with
an
internal
slot
that
would
be
kind
of
the
brand
for
like
well.
C
This
is
a
special
object
marker,
but
I'd
like
the
I
like
how
it
feels
to
to
build
off
of
the
object,
primitive
split
here.
I
also
wanted
to
note
that
for
records
and
tuples,
if
we
go
with
this
current
design
of
having
boxed
objects
inside
of
records
and
tuples-
and
I
know-
we've
talked
about
whether
the
boxes
should
be
implicit,
but
I
think
they
should
be
explicit.
C
B
C
C
D
Kind
of
good
question
in
the
same
vein:
if
we
have
a
way
of
ending
identity
that
does
produce
symbols.
To
my
knowledge,
there
wouldn't
be
anything
to
have
a
corollary
where
we
could
vend
an
identity.
That
is
an
object
later
on,
in
particular,
one
thing
that
I've
seen
in
the
past
that
I've
never
had
a
practical
use,
for
it
is
wrapping
a
proxy
around
these
vended
identities.
C
D
You're
trying
to
make
so
essentially
you
have
a
box.
I
don't
have
a
good
word
for
this.
This
is
getting
weird.
You
have
a
proxy
around
a
unique
identity.
That's
used
to
map
to
values,
and
so,
when
you
perform
actions
on
the
proxy,
you
can
use
the
real
identity
for
it
with
a
symbol,
you
can't
wrap
them
in
any
way.
I've
never
had
a
practical
use
case
for
this,
but
it's
just
something
to
note.
D
E
And
we
have
talked
about
that
in
the
past.
Like
do
you
really
want
to
disable
access
to
a
particular
symbol?
For
example,
you
can
construct
a
symbol
on
the
other
side
of
the
membrane
and
somehow
have
these
two
symbols
to
represent
the
same
thing,
but
in
two
different
realms.
So
you
don't
even
share
the
symbols,
but
normally
you
would
just
share
the
symbol,
and
that
should
be
fine
cross
realm.
They
work
pretty
well.
E
F
C
C
A
C
We
had
the
you
know.
There
were
like
the
arguments
between
you
and
jordan
about
right.
How
things
in
symbol.4
should
be
treated,
and
I
guess
the
in
in
my
proposal.
Symbol.4
symbols
would
be
permitted
as
weak
map
keys,
even
though
they're
held
alive.
Just
like
you
know,
a
radar
prototype
can
also
be
a
weakness
of
key,
even
though
it's
not
going
to
die
either.
A
Yeah
just
to
to
to
just
completely
flesh
that
out.
I
agree
with
the
I
agree
with
where
that
landed,
but
to
completely
flesh
that
out,
array.
or
array.prototype
is
not
an
adequate
example,
because
it
can
great
garbage
collected
when
it's
realm
is
garbage
collected,
whereas
the
symbol.4
is
forever
the
example
that
was
fully
convincing
is,
if
you
take
the
weak
map,
and
you
store
it
in
itself
as
a
key,
then
the
key
necessarily
has
the
white
lifetime.
As
long
as
the
weak
map
itself.
E
C
Think
this
is
quite
misguided
as
a
as
a
path
to
to
look
down.
I
don't
think
we
should
be.
You
know
pushing
for
the
expectation
that
such
a
collection
would
take
place.
I
think
it's
more
that
not
everything
that
you
put
as
a
weak
map
key
might
be
collected.
I
think
that's
the
argument
that
should
be
made
instead.
A
Yeah
for
a
I
agree
with
daniel
b
coretti
there's
there.
The
impossible
case
is
that
you've
stored
an
association
in
a
weak
map.
That's
still
alive
from
the
symbol.4
of
something
to
some
value,
the
no
matter
how
collectible
the
symbol
itself
seems
to
be
that
association
has
to
stay
there
if
somebody
reconstructs
the
same
symbol
and
looks
it
up
in
the
same
weak
maps.
I
just
don't
see
that
it's
possible
to
do
better
than
that.
C
E
A
A
A
E
Additionally,
I
want
to
add
that
jdd
and
myself
we
worked
on
a
initial
changes,
or
at
least
some
prototype
with
the
near
membrane
that
we
use
today
in
production,
and
now
we
went
very
far
on
to
that.
We
could
do
the
same
with
the
symbols,
see
if
there's
anything
that
pops
there.
I
I
I
don't
believe
there
will
be
any
issue,
but
I
can
work
with
jdd
and
leo
and
on
just
ratifying
that.
E
A
I
think
that
would
be
wonderful.
The
near
membrane
is
the
most
different
compelling
example.
So
if
we
can
do
the
transparent
membrane
and
the
near
membrane,
remembering
is
basically
satisfying
a
very
different,
very
valuable,
strong
transparency,
property,
strong,
practical
transparency
properties,
so
the
kind
of
opposite
transparency
properties
being
able
to
show
both
with
one
underlying
mechanism
providing
the
separation
guarantee
would
be
wonderful.
E
Now
I
was
asking
about
the
tactical
thing,
because,
obviously
we
need
to
continue
discussing
this
with
google
and
I
I
can
try
to
get
shu
and
and
maybe
even
dominic,
to
provide
some
feedback
on
eliminating
the
structural
clone
from
the
picture
and
and
how
far
we
can
go
without
that,
I
obviously
they
have
the
use
cases
from
google,
amp
and
other
use
cases
that
they
have.
Is
it
going
to
be
sufficient
without
the
serialization
and
and
obviously
they
will
have
to
do?
E
E
If
everyone
is
okay,
I
can
I
can
try
to
get
the
ball
rolling.
There
see
how
far
we
can
go
if,
if
it
turns
out
that
it's
fine
for
them
to
have
a
structural
cloning
right
now
and
just
having
a
what
we're
proposing,
then
then
it's
fine,
but
if
there
is
a
push
back,
then
maybe
we'll
have
to
work
something
out.
E
For
for
the
content
proposal,
they
they
did
like
dominic,
provide
a
fair
enough
information
for
us
to
understand
the
api.
I
still
disagree
with
part
of
the
api
and
we
that's
the
area
that
I
want
to
touch
on,
maybe
today
as
well
what
the
mechanism
they're
providing,
because
you
need
to
have
mechanisms
to
push
into
the
realm
and
get
things
out
of
the
realm,
and
those
are
two
different
ways
that
we
need
to
define
two
different
apis.
E
E
E
Their
their
implementation,
they
call
it
eval.
I
wanted
to
call
it
something
else,
because
I
think
it's
misleading
to
call
it
eval,
and
maybe
we
can
call
it
something
else
that
you
have
synchronous
execution
of
that.
There
is
also
the
open
question
about
the
import
it's
like
when
you
call
import
on
the
rom.
What
does
he
return?
Is
it
returns
a
promise
that
resolves
to
what
so
you're
loading
a
module?
But
what
does
it
return
to
you?
And
additionally,
there
is
the
problem
of
calling
things
into
the
realm.
E
So
they
have
these
ideas
so
to
facilitate
people
to
set
it
up,
set
up
the
the
rom
initially
and
potentially
doing
some.
Some
other
calls
into
the
some
reference
that
you
have
in
in
the
realm
and
finally,
he's
proposing
to
define
a
a
global
global,
binding,
the
name
of
a
global
binding
that
will
be
installed
inside
the
rom.
E
E
You
can
set
it
up
in
such
a
way
that,
when
the
program
running
is
either
on
calls
full
as
a
function.
That
is
a
invocation
of
the
callback
that
they
provide
when
constructing
the
rom.
That's
the
api
that
they're
proposing,
I
think,
that's
cumbersome,
and
maybe
we
can
simplify
that
or
just
simply
provide
a
mechanism
for
someone
to
define
these
communication
mechanisms
between
the
rom
and
the
incubator
round.
A
E
Sharing
my
screen
here
just
to
try
to
give
you
a
little
bit
of
a
sense
what
they
have
in
mind.
So
this
example
is
probably
the
prime
example
where
you
construct
a
rom.
You
can
evolve
things
and
it
might
return
a
minor,
not
return,
something.
We
need
to
figure
out
what
happened
when
this
evolves
returns,
something
that
cannot
be
returned
to
the
outer
incubator
realm.
E
So
if,
if
the
return
of
this
is
a
function
or
an
object
or
something
will
happen
in
their
case,
they
were
they're
proposing
a
structural
cloning
in
our
proposal,
we'll
have
to
figure
out
what
that
response
will
be.
That's
one
thing.
The
second
thing
is
that
they
are
providing
these
utility
methods
like
call
get
and
such
in
this
case,
they're
saying
inside
is
rom
intense,
invoke
a
global
function
that
should
be
there,
and
these
are
the
arguments
that
you
should
use
and
the
return
of
that
operation
gets
returned
back
to
the
outer
incubator
realm.
E
C
E
This
callback
gets
invoked
whenever
the
program
inside
the
realm
is
invoking
a
global
reference
called
call
pattern,
so
it's
kind
of
installing
a
function
inside
the
realm.
So
when
that
function
gets
invoked,
it
really
just
calls
this
callback
that
was
used
during
the
creation
of
the
realm.
That's
the
proposed
there's
nothing
else.
This
is
what
they're
proposing
there's,
it
doesn't
say
anything
about
errors
and
what
happened
when
you
try
to
evolve,
and
there
is
an
error
inside
the
program,
how
we
perceive
these
error
from
the
incubator
realm,
and
so
on.
E
My
I,
my
proposal
is
to
have
something
a
little
bit
more
simpler.
That
goes
around
similar
to
the
call
in
this
case
or
a
set.
I
would
say
more,
like
I
said
where
you
can
create
this
connection
between
the
two
realms
by
defining
a
this
callback.
Mechanics
that
you
can
install
at
any
given
time
doesn't
have
to
be
during
construction
of
the
realm.
E
It's
something
like
if
I
have
a
rom,
I
can
decide
to
place
a
function
in
in
a
in
the
global
scope
of
the
realm
in
the
global
object
by
calling
an
api
that
defines
what
would
be
that
name
and
what
will
be
the
callback
when
that
function
is
invoked.
So
let's
call
it
a
round
up,
install
callback
function
into
the
rom,
something
like
that
and
and
that
thing
allows
you
to
define
this
mechanism
before
and
after
evaluation.
E
E
F
Clarification,
if
I
may
about
five
minutes
ago,
you
were
suggesting
that
there
be
a,
as
I
heard,
a
suggestion,
whether
it
was
from
you
or
from
these
other
parties
that
there
be
a
default
name
assigned
to
such
a
callback
function.
But
now
you're
saying
no,
that's
not
what
you
intended.
You
intended
for
the
creators
of
the
realm
to
specify
a
name
for
this
callback
interface.
That's.
E
F
E
F
Second,
my
second
concern
is
that
this
is
allowing
the
owner
of
the
realm
the
creator
of
the
I'm
sorry
the
owner
of
the
realm,
to
define
globals
that
would
allow
it
that
would
allow
code
inside
to
maybe
detect
that
it
is
in
a
contained
realm
versus
javascript
running
right
at
the
top
level.
That
would
not
have
that
kind
of
detection.
E
E
A
A
A
C
Yeah,
I
share
mark's
sort
of
surprise
here.
I
think
there
are
probably
simpler
ways
that
we
could
do
this,
that
don't
I
mean
to
me
what
what
like
smells
funny
is
that
all
these
things
involve
kind
of
these
mutation
and
global
variables,
and
I
wonder
if
we
could
have
something:
that's
like
an
api
that
could
look
like
a
realm
dot
create
channel,
and
you
pass
into
that
two
things.
C
The
callback
that
gets
called
when,
when
the
realm
calls
into
it,
and
so
now
you
have
a
bi-directional
kind
of
communication
channel
set
up
but
entirely
just
by
those
two
functions
being
called
in
this
kind
of
symmetrical
way.
I
could
write
this
up
later
and
I
don't
know
it
would
work.
It
would
be
easy
to
use
with
multiple
blocks,
because
that
lets
you
have
in
line.
C
D
E
C
E
D
Yes,
yours
should
work
fine,
because
you
essentially
are
using
parameters
to
solve
things.
I
think
the
return
value
of
it
so
you're
passing
in
a
communication
from
inner
to
outer
as
a
callback.
I
think
the
return
value
as
a
way
to
reinvoke
something
might
be
useful.
So
I
think
that
was
the
last
thing
you
mentioned.
C
C
D
E
E
A
A
You
know
the
the
parent
that
created
the
realm
in
the
realm
that
was
created
and
that's
certainly
the
the
important
place
to
start,
but
one
of
the
things
that
that
quickly
comes
up
by
arrangement
starting
there
is
a
parent
alice,
creates
two
child
realms
bob
and
carol
and
then
puts
them
in
contact
with
each
other.
So
you
just
have
direct
communication
between
realms
that
have
been
put
in
contact
with
each
other
that
are
symmetric.
Neither
one
of
them
is
the
incubator
or
the
other
yeah.
E
C
C
C
E
E
C
A
A
So
I
think,
with
regard
to
the
separation
mechanism,
we're
trying
to
separate
the
object
graphs
so
that
we're
not
sending
objects
across
the
boundary,
but
the
control
flow
signals
that
go
the
nature
of
the
control
flow
that
goes
across
the
boundary
should
just
be
the
nor
all
the
normal
javascript
control
flow.
We
shouldn't
be
doing
anything
to
change
the
nature
of
the
control
flow,
so
you
can
still
on
the
throwing
side,
throw
primitive
data
that
then
is
caught
on
the
other
side
and
turned
back
into
object.
That
is
then
re-thrown.
C
D
There
is
no
way
you
can
properly
try
catch
around
it.
You
have
to
use
the
host's
hook
for
that,
so
if
they
are
allowed
to
provide
anything
similar
to
that
or
you're
able
to
recreate
it
inside
the
realm,
you
can
get
into
cases
where
you
can't
introduce
an
async
barrier
that
has
a
try
catch
around
it.
I
don't
know.
C
C
Oh
yeah,
I
don't
know
how
to
do
that
either.
I
mean
overall,
this
direction
seems
like
more
of
an
expert
level
api
than
the
previous
realm
proposal.
Like
we
have.
We
have
many
expert
level
apis
in
javascript.
We
have
proxies,
for
example,
that
you
can't
just
start
using
a
proxy,
because
there's
just
a
lot
to
learn
and
realms
that
are
restricted
in
this
way
would
would
be
one
of
those
expert
level
apis
as
well,
and
I
think
that's
true
whether
no
matter
which
option
we
go
with.
A
E
E
And
and
then,
if
you
have
any
idea,
you
can
articulate
a
a
good
api
that
allows
to
do
this.
Communication
that'll
be
great,
daniel
I'll
bug
you
in
the
next
couple
of
days
to
get
some
some
from
you
and
then
we
can
go
from
there.
For
now.
I
will
just
focus
the
energies
and
trying
to
convince
google
that
primitive
values
are
the
way
to
go
rather
than
the
structure
clan
mark.
You
said
that
you
will
be
doing
some
write
up
or
some
some
some
material
about.