►
From YouTube: SES Meeting: Refactoring Multi-facet Membranes
Description
Alex Vincent led a discussion about a design challenge for multi-facet membranes and we also briefly discussed module fragments with Daniel Ehrenberg.
A
B
B
B
B
It
does
add
some
complexity,
but
at
the
same
time,
if
I
can
test
that
things
are
working
well,
this
brings
a
couple
of
benefits
which
the
first
one
is.
It
makes
it
much
easier
to
inject
a
distortion
proxy
handler
if
it's
based
on
one
that
is
based
on
a
class
that
can
fit
into
this
graph
of
proxy
handlers,
not
graph
of
objects,
graph
of
proxy
handlers
and
two,
like
I
said,
unit
testing.
B
So
let
me
just
walk
through
the
basic
idea
here.
The
one
thing
about
proxy
about
when
you
call
proxy.
revocable,
you
have
to
pass
in
a
proxy
handler
and
that
proxy
handler
is
tied
to
the
proxy
forever,
but
there's
nothing
in
the
rules
that
says
that
that
proxy
handler
can't
be
a
single
component
say
a
head
of
a
linked
list,
which
is
where
my
original
idea
started,
or
in
this
case
a
simple
directed
graph.
B
B
B
B
It
does
some
settings
like,
for
instance,
if
the
real
target
is
sealed
or
frozen,
you
want
to
seal,
you
want
to
populate
and
then
seal
or
freeze
the
shadow
target
right
away,
and
then
you
want
that
initialization
proxy
handler
to
just
drop
off
the
graph.
As
far
as
that
particular
proxy
is
concerned,
now
you'd
still
keep
it
in
the
in
the
graph
for
creating
future
proxies.
B
C
B
B
C
B
Both
I'm
not
at
the
point
where
I'm
ready
to
implement
this,
yet
I've
started
some
explorations
at
first.
I
was
thinking
a
linked
list
and
then
I
thought
about
conditions
where
I
might
want
to
jump
from
one
proxy
handler
over
several
others
to
another,
and
then
I
realized
you
know
what
a
linked
list
is
not
adequate
for
this,
and
that's
why
I
came
up
with
this
image
describing
math
and
what's
whether
in
mathematics,
it's
called
a
simple
directed
graph.
D
Yeah
alex
this,
this
is
very
similar
to
what
we
do
in
neon
membrane.
We
we
also
make
some
optimizations
on
top
of
these
there's
a
similar
idea,
where
you
have
multiple
handlers
that
can
do
certain
things
and
and
the
distortion
included,
and
so
on.
For
our
case,
we
find
out
that
this
was
too
slow
too
many
function,
calls
like
you,
you
dying
from
thousand
thousand
cuts,
basically
and
everywhere
function
called
call
calls
and
so
on.
D
It
turns
out
that
it
is
actually
very
useful
for
membranes,
so
at
any
given
time
when
we
determine
that
you're
making
a
particular
change,
whether
that's
because
you
are
trying
to
freeze
the
proxy
itself
and
we
determine
that
and
make
the
adjustments
or
because
you
are
accessing
a
a
you're
you're
checking
if
it
is
extensible
in
proxy
extensively.
At
that
time
you
go
and
check.
If
the
real
target
is
extensible
and
you
determine
that
it's
not,
then
you
have
to
do
the
proper
freezing
of
the
shadow
target.
D
D
Doesn't
do
really
anything
it's
just
checking
if
he
needs
to
do
something
and
then
jump
to
the
next
one
and
so
on
and
and
then
secondly,
we
reduce
we
were
able
to
reduce
the
the
the
handler
for
a
sequence
to
a
single
handler
and
when,
when,
when
the
optimization
is
the
last
optimization
like
the
case
of
rose-
and
it
is
what
it
is
it's
frozen
already.
So
you
know
you
don't
have
to
do
many
jumps.
There
is
no
distortion.
It's
nothing!
D
It's
just
straight
to
get
the
value
out
of
of
the
of
the
shadow
target,
so
we
do
a
lot
of
those
optimizations
and
we
we
were
able
to
get
it
down
to.
I
think
five
case,
and
I
still
hope
that
for
the
work
that
we're
doing
for
realms,
I
can
get
it
down
to
a
couple
of
case
in
size
and
it's
pretty
fast.
It's
really
really
fast.
E
D
C
D
And-
and
we
do
we
exactly
have
the
same
thing-
it's
actually
called
initialize
the
thing.
If
I
remember
correctly,
it's
the
same
thing
like
we
run
it
once
once
we're
ready
to
do
any
operation
on
it
and
we
we
we
do
the
tricks
of
at
any
given
trap.
We
call
initialize,
we
optimize
the
initialize,
so
it
happens
only
the
first
time,
the
next
time
it
doesn't
do
anything.
It's
a
no
op
function,
so
the
engines
does
they
can
do
a
lot
of
optimization.
D
So
every
trap
calls
the
head
is
basically
a
bunch
of
traps
for
us.
Each
trap
call
initialize
initialize
the
first
time
mute
itself
by
setting
itself
to
no
op.
So
next
next
time
doesn't
do
anything
because
it
was
already
initialized
and
that's
optimized
for
browsers
and
then
from
there
you
go
on
and
and
in
every
trap
you
go
and
try
to
decide.
D
D
Sometimes
you
want
the
membrane
to
simply
just
keep
keep
coming
back
to
the
orino
target
on
the
other
side
and
do
the
operations
there,
but
sometimes
you
don't.
Sometimes
you
want
to
take
kind
of
a
snapshot,
kind
of
thing
where,
if
you
don't
apply
any
mutation
to
it,
you
are
live,
but
the
minute
you
do,
the
mutation.
We
take
the
snapshot
and
that's
the
universe
that
you
see.
D
That's
the
reality
that
you
see
you
do
some
of
that
for
some
objects
and
and
for
that
particular
case,
because
you're
going
through
a
mutation
trap,
we
know
it
is
a
mutation
trap
and
we
determine
that.
That's
the
first
time
that
you're
trying
to
mutate
that
so
we're
going
to
do
some
optimization
for
you
and
then
move
on.
So
those
are
very,
very
interesting
things.
C
D
D
Mutations
like,
if
I,
if
I'm
changing
an
array
prototype
to
a
string
or
something
like
that
or
or
a
red
prototype,
join
you're
only
mutating
your
version
of
join
okay.
It
doesn't
go
through
the
membrane,
so
in
that
case
we
determined
that
this
object
is
special
and
you
don't
you're
not
allowed
to
modify
that
object.
If
you
want
to
modify
it,
we
do
the
modification
on
your
side
of
the
of
the
of
the
graph
and
it
never
goes
through.
D
But
but
if
you
are
not
mutating
and
the
outside
does
change,
they,
they
join
behavior
for
whatever
reason,
because
being
political
or
whatever
you
still
will
get
that
version,
because
you
it
goes
through,
it
doesn't
take
the
full
snapshot.
Does
it
it's
copy
on
right,
copy
and
write?
Yes,
basically,
yeah
take
the
snapshot
on
right,
yeah.
C
B
Okay,
well
just
to
come
back
to
what
carrie
is
saying,
I
think
karity
you
and
I
are
actually
going
in
the
same
direction.
You're
saying
that
this
approach
is
too
slow
and
you
might
be
right,
I
don't
know
yet.
This
is
an
experiment
on
my
part,
but
I
do
know
that
the
complexity
of
my
current
implementation,
which
is
not
this,
is
so
great
that
it
drives
me
up
the
wall.
B
I
can't
really
guarantee
that
what
I've
done
is
correct
and
slowness
and
speed
is
not
going
to
matter
if
you
can't
guarantee
correctness
in
the
first
place,
so
I
think
I'm
still
going
to
proceed
along
these
lines
until
I
have
something
better
to
go
with
and
by
the
way
another.
The
changes
that
I'm
making
in
es
membrane
is
initializing
the
proxy
on
first
access
a
couple
weeks
ago,
I
sent
out
an
email
to
scs
strategy.
I
believe
it
was,
and
I'm
which
means
pretty
much.
B
Let's
say
you
have
object
in
in
one
graph:
a
dot
b,
dot
c
equals
a
so
you've
got
a
cycle,
and
then
all
three
of
those
a
and
b,
are
sealed.
This
causes
a
problem
if
you're
trying
to
define,
if
you're,
trying
to
populate
the
proxy
before
you
return
it
out
of
your
object.
Graph
handler
out
of
your
proxy
handler,
creates
a
huge
problem
and
a
number
of
smaller
problems
that
are
not
immediately
obvious,
and
the
simple
solution
is
don't
do
that.
B
Otherwise,
I
guaran
damn
to
you
you're
in
for
a
world
of
hurt,
and
you
won't
even
know
it,
and
the
sealed
cycle
that
I
mentioned
a
few
min
a
moment
ago
is
only
the
most
subtle
and
painful
of
those
I
wrote
I
had
to
re.
I
ended
up
dropping
400
lines
of
code.
Once
I
fixed
that
problem,
the
delta
was
400
lines
removed
more
than
added.
B
Where
was
I
yeah,
I
lost
my
train
of
thought,
sorry
guys,
so
I'm
just
trying
to
explore
this
and
see
if
I
can
get
it
to
work.
I
do
understand,
there's
a
cost
from
going
from
one
function
and
one
proxy
handler
to
another
to
another
to
another
in
a
linked
list
and
by
the
way
after
the
proxy
is
initialized,
you
wouldn't
have
the
full
graph
for
that.
B
B
Yeah,
I
don't
have
much
else
to
say
on
this
particular
thought,
but
it
does
lead
to
something
else.
That's
been
ruminating
on
my
mind
and
I'm
not
really
ready
to
propose
something
yet
for
for
consideration,
certainly
not
to
tc39
may
not
even
need
them,
but
I
keep
running
into
this
problem
in
membranes
development
and
it's
interesting
where
I
need
two
tuples
or
three
tuples
by
the
way,
I'm
very
specifically
not
talking
about
the
records
and
tuples
proposal
that
is
being
considered
by
this
group.
B
That
would
be
a
composite
weak
map,
where
the
first
key
would
be
your
shadow
target,
and
the
second
key
would
be
your
the
trap.
You're
trying
to
invoke
this
problem
pops
up
over
and
over
and
over
again,
where
you
have
a
composite
where
you
have
a
tuple
of
keys
and
you
have
to
build
data
structures,
compositing
weak
maps
and
maps
together
to
handle
that
it's
not
just
this
case.
B
It
happens
repeatedly,
at
least
in
my
design,
and
it
got
to
the
point
where
I
got
frustrated
enough
to
say:
okay,
you
know
what
I
need
to
not
just
generalize
this
into
a
composed
one,
but
to
actually
pre-generate
to
generate
these
classes
from
a
as
a
compile
step
or
a
build
step.
I'm
not
there.
Yet.
I
don't
have
enough
to
actually
give
a
presentation
to
this
group,
but
I'm
just
putting
the
idea
out
there
that
maybe
we
need
to
think
about
that
more.
B
I
mean
it's:
it's
not
just
this
proxy
handlograph.
It's
if
you
remember
from
the
slide.
I
I
when
I
talked
to
him
about
when
I
talked
about
how
I
go
from
one
object
graph
to
another
with
that
proxy
mapping
which,
by
the
way
I'll
be
renaming
the
proxy
cylinder
for
reasons
I'll
explain
later
it.
Basically,
that
is
a
one-to-one
hash
table.
B
B
C
And
if
that
element
in
the
array
is
a
value,
then
the
corresponding
node
in
the
try
for
indexing
on
it
is
a
map
rather
than
a
weak
map,
and
it
it
composes
together
fairly.
Well,
it
even
does
the
enumer,
it
even
does
the
enumeration,
and
it's
it's
actually
quite
neat,
and
it
sounds
like
it
sounds
like
that.
E
B
E
E
So
the
key
with
composite
key
is
by
having
partial
garbage
collection.
You
can
maintain
the
mapping,
even
though
parts
of
the
mapping
have
been
garbage
collected
out.
So
it's
it
can't
be
on
the
storage
of
the
map
itself.
So
that's
probably
the
only
significant
difference
is
yours
would
garbage
collect.
B
Let
me
say
I
want
to
be
part
of
that
discussion
as
well
mark,
because
mine
might
be
a
third
option
to
consider,
especially
if
I
can
get
it
working
which
again
I'm
weeks
away
from
it,
but
I'm
also
rapidly
developing
it
and
I'm
combining
ideas
at
the
same
time,
including
argument,
validation,
it's
it's
gonna
get
interesting,
but
I'm
not
there
yet.
Okay,
I
don't
have
anything
else
for
this
group.
Thank
you,
chris,
for
sharing
the
screen
here.
D
I
have
only
one
one
comment
which
I
think
related
to
being
able
to
define
what
are
the
things
that
we're
going
to
ask
to
the
community
to
look
at
for,
to
make
it
easy
to
create
membranes
and
so
on.
One
of
the
big
challenges
that
we
have
is
with
the
with
the
with
the
shadow
target
and
the
second
one
is
with
the
when
the
shadow
target
happens
to
be
a
function,
the
name
of
the
function
and
so
on
is
also
problematic.
D
So,
as
a
result
of
that,
we
ended
up
having
to
do
a
lot
of
forking
logic
to
make
the
proper
determination
about
what
the
shadow
target
should
look
like
in
order
to
match
the
real
target,
and
on
top
of
that,
we
have
to
wrap
the
shadow
target
with
another
proxy
in
order
to
provide
the
proper
naming
and
so
on.
For
that,
if
you
happen
to
be
a
function,
I
think
those
those
two
litter
things.
D
D
Especially
when
you
are
proxying
for
us
proxy
in
the
the
intrinsics
and
the
dom
apis
and
so
on,
in
order
to
keep
them
to
to
match
the
original
semantics
and
the
name
of
the
function
so
on.
So
it's
not
observable
for
people
to
determine
that
this
is
a
proxy.
We
want
to
keep
that
proxy
to
match
the
the
name
in
case
of
constructor
and
so
on.
So
I
have
to
look
back
at
the
code,
but
we
do
have
some.
D
C
D
For
all
properties,
you
know
length
is
also
another
one,
so
length
and
and
name
and
so
on,
because
you
don't
really
define
the
function.
So
there
is
no
argument,
there's
nothing
there,
so
the
length
will
not
match
so
you
do
a
proxy
around
it.
So
it
does
match
when
it
comes
to
decide
what
kind
of
lamp
you
have
and
what
the
name
of
the
function
and
so
on.
B
C
I'm
just
not
I'm
just
not
following
the.
If
you
just
do
a
normal,
transparent
membrane,
then,
when
the
real
target
is
a
function,
the
shadow
target
is
a
function
and
when
the
the
real
target
has
a
name
and
length
property,
you
would
set
the
name
and
length
property
of
the
shadow
target
to
reflect
the
real
target
in
just
the
way
that
you
do
any
other
property
handling.
I
don't
understand
why
there's
a
difference.
D
D
B
B
B
C
B
D
B
F
So
the
two
topics
I
wanted
to
raise
one
was
about
going
into
more
detail
on
that
idea.
That
mark
presented
from
peter
about
multi-threaded
code
based
on
a
single
realm.
That's
shared
across
threads
and
the
other
topic
was
about
module,
fragments
which
mark
volunteered
to
co-champion,
and
so
I
just
wanted
to
kind
of
talk
through
the
future
in
some
more
detail
than
we
have
previously.
But
I
don't
know
if
either
of
those
fits
in
10
minutes.
F
C
Yeah
one
one
particular
thing
that
we
need
to
better
understand
is
module
blocks,
create
the
static
concept,
the
unlinked
uninitialized
thing
that
can
spawn
initialize
linked
modules,
whereas
module
fragments.
If
I
remember
what
you're
what
you
get
when
you
you
know
what
the
module
fragment
evaluates
to
is
a
normal
linked,
initialized
module.
It
doesn't
directly
do
well
or
refine
the
static
concept.
F
C
Right,
that's
what
I
mean.
So
one
thing
that
I've
been
thinking
about
is
we've
got
okay
this
this?
This
is
not
something
I've
talked
through
with
anybody,
and
it's
so
it's
probably
ill-formed
in
my
head,
but
does
it
make
sense
to
say
to
take
let's
say
our
our
import
declaration
in
general
and
have
a
form
of
it
where
let's
say
you
precede
it
with
the
static
keyword,
static,
import
and
then
you
know
the
the
and
then
module
specifier
and
what
you
get
back
is
a
static
module
record.
F
F
F
C
F
C
Well,
so
yeah,
so
so
the
particular
syntax
might
not
be
ideal,
but
the
idea
that
you,
just
whatever
the
resolution
machinery
is
that
you
find
a
way
to
engage
it
up
to
the
point
that
it
gives
you
the
static
module
record
as
a
refined,
static
module
record.
So,
for
example,
under
the
compartments
abstractions
for
manipulating
import
namespaces,
once
you've
got
the
static
module
record,
you
could
then
reuse
it
in
another
context
linked.
You
know,
initialized
and
linked
differently
with
a
different
different
set
of
import
bindings.
F
Basically,
an
import
statement
can
get
you
an
absolute
url
from
a
relative
one
and
tell
the
build
machinery
that
you
want
this
asset,
where
the
asset
might
be
an
image,
for
example,
and
you
import
it
and
you
get
an
absolute
url
that
you
could
then
use
in
an
image
tab
or
something,
and
this
kind
of
static
import
link.
Semantically
corresponds
to
that
use
case.
F
E
I
do
know
that
it's
like
that
metadot
resolved
is
probably
forever
blocked
because
webb
wanted
it
demanded.
It
be
synchronous
and
node
can't
make
it
synchronous
for
a
variety
of
reasons,
so
that
one's
probably
out
the
window.
There's
the
old
asset
references
thing,
and
maybe
that
would
be
useful
instead
of
coming
up
with
a
entirely
new
semantic.
E
F
E
E
E
A
A
A
hard
problem
to
solve
without
chain
with
without
have
without
introducing
a
new
notion
of
what
a
css
module
is
that
is
distinct
from
what
like
the
import.
Semantics
of
css
are
disjoint.
The
import
semantics
of
html
are
disjoint,
creating
the
notion
of
an
html
module
and
the
notion
of
a
css
module
that
participates
in
esm
would
be
or
participates
in.
A
A
shared
notion
of
of
loading
would
be
super
valuable,
like,
for
example,
one
of
the
one
of
the
frustrations
I
had
as
a
web
developer,
and
I
don't
know
how
far
along
we've
gotten
since
but
like
five
years
ago,
was
that
you
couldn't
say
in
your
html
file.
You
can't
say
refer
to
an
asset,
that's
provided
by
a
different
node
package
without
reaching
into
the
node
modules
hierarchy,
which
is
brittle.
F
F
You
know
chris
mentioned
the
the
where
the
package
manager
puts
the
stuff
and
that's
totally
solved
by
import
maps.
Maybe,
and-
and
you
know
there
are
proposals
for
what
how
html
and
css
module
semantics
should
be,
but
these
don't
you
know,
turn
over
and
replace
how
html
and
css
loading
work.
They're
sort
of
you
know
very
localized,
incremental
modifications
right,
so
I
kind
of
feel
like
whatever
we
do
should
be.
You
know
in
the
in
this
thing
that
we
started
off
on
about
a
static
import
form.
A
A
A
F
F
F
So
there
are
variables,
but
you
would
be
able
to
import
them
because
there
would
be
this.
You
know
correspondence
with
something.
That's
statically
analyzed,
and
this,
I
think,
has
some
benefits
in
terms
of
providing
a
unified
medical
model
together
with
module
blocks,
because
we
would
say
that
the
value
of
that
variable
is
that
static
identifier.
Is
that
static
module
value?
You
know
this
would
only
work
for
multiple
fragments
module
blocks.
It
wouldn't
work
for
other
things
that
you
want
to
import
but
and
the
correspondence.
F
I
wanted
to
talk
about
that
with
this
group,
because
I
think
this
group
adds
a
good
amount
of
rigor
to
these
kinds
of
analyses.
I
you
know
I
initially
shied
away
from
this
kind
of
pund
name
space
idea,
because
it
seems
I
don't
know
it
feels
a
little
bit
risky
somehow
in
a
vague
way.
But
I
can't
I
can't
think
of
any
correctness
issues.
It
seems
completely
doable
in
a
throwaway.