►
From YouTube: SES Meeting: Module constructor tail arguments
Description
Wherein we discuss the pedagogy of the Module and importHook interfaces and the possible need for an arguments bag.
A
All
right,
it's
the
cess
meeting
today
is
august
17..
We
only
have
we've
decided
to
defer
the
topic
of
whether
to
break
the
compartment's
proposal
onto
smaller
topics
to
a
future
meeting
when
we
can
have
a
quorum
on
that.
For
now,
karate
has
suggested
that
we
discuss
the
ergonomics
of
the
module
constructor.
B
C
C
If
we
don't
have
any
of
this,
and
we
just
let
it
be
on
the
on
the
input
on
input
hook
and
specifically,
that
you
can
create
an
input
hook,
that
is
that
has
sufficient
information
via
the
closure
to
know
what
the
referral
is,
and
we
did
touch
on
it
briefly,
but
we
didn't
want
too
deep
into
it.
I
think
this
the
proposal
from
niccolo
is
to
either
make
the
argument
to
be
a
generic.
C
It's
not
really
a
referral,
it's
just
some
context,
object
of
some
sort
and
this
contact
object
will
contain
whatever
you
want
it
to
contain.
We
know
it
could
be
anything
whatever
it
is.
We
don't
care,
and-
and
so
that's
not
different
from
what
we
have
right
now.
In
fact
it
is
whatever
you
want
you
can
put
in
all
or
whatever,
so
we
don't
prescribe
that
it's
really
just
a
renaming
comes
in,
but
they,
I
think
the
reflection
of
this
is
basically
that
this
is
the
ergonomic
improvements
that
we
did
on
the
api.
C
By
saying
you
can
pass
whatever
you
want.
We
don't
care
about
what
you
pass.
We
will
just
propagate.
We
will
never
use
it,
we'll
never
try
to
hold
on
to
it.
We
just
store
the
volume
and
give
it
back
to
you.
You
can
still
do
the
same
if
you're
doing
binding
a
dot
bind
or
you
can
create
a
input
per
incomes
that
you
create
and
that
might
contain
sufficient
information
about
what
you
want
to
do
and
so
on.
C
So
it's
really
about
whether
or
not
we
do
want
these
ergonomic
improvements
there
and
if
we
do
want
it,
make
it
a
little
bit
more
clear.
I
will
say
that
the
argument
that
you
pass
is
just
for
you
to
receive
it
later
on.
We
don't
do
anything
with
it.
I
think
that's
kind
of
the
concern
that
I
have,
because
this
is
a
very
low
level
api.
You
could
do
this
and
use
a
line.
A
A
A
C
D
A
D
D
So,
like
the
the
question
here
is
mostly:
do
we
want
to
give
a
way
to
pass
the
metadata
which
could
be
like
a
metadata,
also
includes
the
referrer,
or
do
we
do?
We
just
ask
people
to
do
that
by
themselves
by
using
a
closure
or
by
like
using
bin,
to
pass
some
context
limber
hook
before
passing
it
to
the
module
constructor.
A
We
should
also
allow
the
referrer
to
be
an
arbitrary
object
so
that
functionally
it
can
be
used
in
the
way
you
describe,
I
think
naming
it
refer
is
helpful
for
indicating
what
we
expect
common
usage
to
be,
whereas
and
also
allowing
it
to
be.
An
arbitrary
object
allows
us
to
open
up
more
some
of
these
additional
use
cases
leaving
the
refer
argument
out
of
the
import
hook.
I
think
is
again,
although
it
can
be
made
to
work
by
using
closures.
D
I,
like
my
main
suggestion,
was
to
rename
it
to
something
else,
because
it's
like,
even
if
we
might
expect
people
to
just
pass
a
string
there.
This
can
be
much
more
and
it's
strange
to
name
an
argument
based
on
some
expected
usage.
That
does
not
reflect
what
the
like
the
spec
algorithm
expect
it
to
be.
D
D
D
A
I
still
so,
let's
concretely
contrast
leaving
the
name
as
referrer,
in
which
case
it's
referrer,
specific
metadata
versus
naming
it
something
like
context
or
meta,
so
meta
is
right
out.
Obviously,
that
would
be
confusing.
Context
is
also
very
vague
as
a
standalone
word.
It's
like
utils
or
manager,
or
something
like
that
is
like
what
what
kind
of
context
is
this?
I,
I
think
that
having
the
name
be
referrer
that
the
name
referrer
can
be
seen
as
this.
D
A
B
C
Yeah,
so
so
a
couple
of
comments
on
these,
not
specifically
what
you're
talking
right
now,
but
in
general
I'll
say
that
there
are
many
apis
today
that
I
can
think
of
that
will
do
these
sort
of
things,
the
closest
one.
I
think
nicolo
mentioned
the
array
methods
where
you
can
pass
it
this
argument
or
something
like
that
on
the
callbacks
for
the
callback
that
this
argument
could
be
a
possibility
here
as
well.
Although
it
might,
it
might
be
a
little
confusing,
I
would
say,
but
there's
some
precedent
about
that.
A
C
I
so
that's
one
comment.
The
second
comment
is
that
I
understand
that
the
referral
is
an
important
concept
when
you
have
this
thing,
that
controls
multiple
modules
or
as
a
master
puppet
of
multiple
objects,
multiple
modules
in
this
case,
but
the
reality
is
that
this
new
api
is
not
about
controlling
a
set
of
modules.
It's
about
controlling
one
module
at
a
time
that
made
me
think
that
the
concept
of
referral,
maybe
is
not
a
thing
that
aligns
well
with
the
principles
of
this
new
api.
C
We
can
omit
it
all
together
and
there
is
no
referral.
You
have
one
module.
You
have
the
hook
for
the
module.
You
figure
it
out
at
the
low
level.
You
can
do
all
these
kind
of
things
you
can
do
if
we
want
to
introduce
the
concept
of
this
argument,
I'm
fine
with
that,
because
it
is
a
callback
and
then
you
can
receive
a
deal
value
in
that
callback
if
you
want
to
otherwise
you
get
undefined.
C
So
that
seems
more
simple,
to
explain
more
simple,
to
teach
right
now,
when
I
was
writing
some
of
the
examples.
If
it
doesn't,
it
doesn't
feel
to
me
that
is
very
easy
to
teach.
Okay,
you
have
to
pass
this
argument
here
and
then
you
will
receive
the
same
argument
down
here
in
the
same
callback
that
you're
passing
in
the
argument
after
the
argument
that
you're
passing
it
like
yeah.
How
do
you
explain
that
to
people
so
it
becomes
a
little
bit
of
a
from
the
teachability
point
of
view.
C
A
A
C
Okay,
so
a
couple
of
notes
on
these,
I
think
it's
important
to
highlight
that
the
current
api,
the
rename
api,
the
new
api
with
this
value
and
the
api
without
this
volume,
without
the
referral
they
all
have
the
same
capabilities.
This
is
all
about
ergonomics,
so
they
all
have
the
same
capabilities.
The
economics
and.
C
Sure,
I'm
not
talking
about
performance
talking
about
capabilities,
so
the
the
performance
is
something
that
we
can
chat
about,
but
they
all
have
the
same
capabilities.
You
can
build
the
same
thing
out
of
that
it
doesn't
matter
which
one
we
choose
when
I
was
talking
about
the
teachability
of
it.
So
normally.
C
What
I
use
for
this
case
is
that
I
focus
on
what
what
it's
called
the
the
song
of
proximal
development.
So
you
learn.
First,
you
can
build
and
in
terms
of
a
module,
you
can
resolve
the
things
for
that
module
first
and-
and
you
do
that
by
providing
a
hook,
that's
specific
to
that
module,
and
then
you
go
to
the
next
stage
and
the
what
we
call
the
the
the
proxy
proximal
development
like
you're
gonna,
learn
how
to
make
it
more
complex.
C
I
don't
see
that,
because
you
have
to
jump
in
and
say
there
is
this
thing
here
we're
going
to
talk
about
that
later,
but
this
thing
here
for
now
put
it
on
the
phone:
okay,
unacceptable,
so
yeah
from
that
perspective,
then
this
value
makes
more
sense.
Because,
then
you,
what
you
do
is
you
you
teach
in
the
simple
api
and
then
you
teach
them
that
if
they
need
to
share
their
hook,
what
they
need
to
do
is
to
add
this
new
thing,
which
is
the
last
argument
and
call
this
item.
C
So
that's,
okay,
you
see
that
they
they
how
they
they
they
they
develop
their
the
knowledge
base
based
on
adding
new
things
to
the
api.
From
that
perspective,
that's
where
I
disagree
with
the
current
api.
It
feels
very,
very
unnatural
when
you're
writing
the
first
thing,
which
is
the
creative
thing,
the
result
of
this
other
thing,
and
that's
it
right.
A
So
so,
if
I'm
so,
I
for
one
totally
agree
that
having
an
api,
that's
designed
for
the
purposes
of
a
graduated
tutorial
that
formally
ignores
concepts
until
they're
needed
for
complications
is
good,
and
I
think
that
having
the
referrer
as
the
second
argument
of
the
import
hook.
So
it
satisfies
that
nicely
because
you
don't
have
to
in
the
first
in
the
first
draft
of
on
your
first
essay
of
understanding
how
to
construct
a
module.
A
Option
I
understand
yeah
okay,
so
I
am
amenable
to
moving
it
rightward,
I'm
the
moving
the
the
res
the
refer
argument:
rightward,
I'm
also
amenable
to
making
it
an
optional
argument,
since
null
is
a
reasonable
default
for
it.
So
what
are
we
considering
for
the
argument
order
that
we
we
know
that
we've.
I
believe
that
we've
agreed
that
the
first
two
arguments
are
source
and
import
hook,
correct.
C
So,
at
least
in
my
mind,
it
is
going
it's
going
to
the
source,
the
koba,
the
meta
that
can
be
accessed
by
the
source
and
then
finally,
a
thing
that
you'll
be
able
to
access
from
within
the
hook
in
whatever
shape
or
form
you
access
from
within
the
hook.
That's
a
separate
conversation
but
kind
of
that.
That's
the
order
that
I'm
I'm
I'm
tuned
into.
A
C
Discriminate
which
one
is
the
one
that
they're
passing,
because
neither
of
those
you
care
about
what
the
shape
of
it
is.
That's
correct
that
you
only
check
that
it
happens.
If
it
is
not
null,
it
happens
to
me
needs
to
be
no
no,
and
if
it
is
not,
if
it
is
provided,
then
it
must
be
an
object,
whether
that's
new
or
an
actual
qualifying
object,
but
that's
the
only
distinction
there.
A
D
Okay,
so
I
prefer
to
have
this
referral
argument
as
last
one,
but
it
has
a
big
problem,
which
is
we
wouldn't
be
able
to
add
new
parameters
because
they
would
be
like
after
the
last
one
like
yeah
one
day,
we'll
have
import
assertions
and
we
will
probably
need
a
new
hook
for
import
assertions.
And
where
do
we
add
this
hook?
If
you
already
have
something
which
is
supposed
to
be
the
last
argument?
D
C
C
So
what
happened
with
proxies
is
that
every
time
that
you
need
to
call
a
hook,
you
need
to
look
up
for
the
hook
on
the
opt
that
is
given
to
you,
the
handler
so
there's
a
performance
penalty
there
that
you're
paying
we
could
choose
not
to
do
that.
We
could
choose
to
pick
up
then
and
get
them
in
memory
and
then
get
away
with
that.
But
we
have
to.
We
have
to
be
more
specific
about
that
kind
of.
C
We
don't
have
much
precedent
on
that,
but
even
in
if
those
are
the
cases,
if
you
go
with
the
object,
then
I
would
say
that
then
the
argument
is
not
needed
anymore,
because
you
use
the
object
that
is
given
to
you
as
the
actual
this
value.
When
you
call
those
hooks,
there
is
a
precedent
in
html,
which
is
good.
C
It
is
the
the
hooks
on
the
web
components
api.
So
when
you
create
a
web
component
class,
when
you
declare
a
class-
and
you
define
that
class
at
the
moment
of
definition
of
the
class,
we
extract
the
hooks
which
is
connected
by
text.
It's
gonna
combine,
adopt
comeback
and
activity
change,
combat
and
even
more
data
that
we
pass
the
the
list
of
activities
that
are
observable.
So
we
extract
that
from
those
objects
and
we
hold
on
to
them
and
then
we
need
to
call
them.
C
We
call
them
and
it
doesn't
matter
what
you
do
in
the
construction
path
or
whatever
doesn't
really
matter
on
the
intense
level
even
before
transition,
which
is
a
good
precedent.
I
would
say
it
works
well
for
the
web
sometimes
confusing,
but
it
works
but
the
and
they
still
use
the
constructor,
which
is
the
this
itself
during
the
construction
path.
So
I
will
say
that
the
that
president
will
might
work
well
for
the
module
system,
but
it
will
be
a
little
bit
more
complicated
and
it
it
eliminates
the
necessity
for
that
argument.
C
C
Yeah
but
it
was
initially
in
the
in
the
option
box
the
problem,
so
at
least
what
I
remember
jack
is
that
the
option
box
was
problematic
because
the
hook
is
required
and
because
the
hooks,
the
hook
in
this
case
the
input
is
required.
You
cannot
have
it
on
the
fine
and
I
can
explain
why.
But
that's
the
reality
right
now.
It
cannot
be
undefined
so
having
an
option
back.
That
has
only
one
thing:
there
seems
like
a
little
oh
I'll
say.
C
The
reason
why
it
cannot
be
undefined
is
because,
if
it
is
undefined,
then
what
do
you
use?
The
only
choices
that
you
have
is
to
make
it
a
default
book
that
does
what
the
browser
normally
do.
But
for
that
to
function,
the
hook
has
to
receive
a
referral
module
record,
and
there
is
no
referral
module
record
at
that
time
that
you
can
use,
because
you
don't
know-
and
if
you
want
to
use
it,
the
one
that
creates
the
intent
that
makes
it
difficult,
because
then
that
makes
the
system
contextual.
C
B
B
C
C
B
C
Yeah
you
can
you
cannot
do
that
for
the
reason
that
I
explained
before
if
the
input
hook
is
now
path,
what
are
you
going
to
build
you're
going
to
build
the
one
that
uses
the
default
behavior?
What
is
the
default?
Behavior
is
the
one
that
we
drafted
in
the
in
the
in
the
block
module.
That's
a
good
example.
Maybe
we
you
can
look
at
that
one,
but
if
you
look
at
that,
one
that
we
use
in
the
let's
say,
readable
pr
here.
C
C
A
The
evaluator's
proposal
is
going
to
necessitate
that
there
be
an
internal
slot
on
the
module
constructor
that
is
analogous
to
the
context
slot
on
the
function
constructor
and
which
is
to
say
that
the
context
doesn't
have
to
be
from
dynamic
scope.
It
is
a
property
intrinsic
to
the
instance
of
the
module
constructor.
C
D
C
The
new
module,
or
is
it
the
global
script
like
in
this
case
no
script
or
no?
What
is
the
referral
you
don't
have?
The
referral
you
have
to
you
have
to
you
have
to
find
a
referral
which
one
is
it?
It's
ambiguous.
You
don't
know,
and
if
you
want
to
make
it
the
module,
then
you
have
to
make
it
contextual
meaning.
If
I
grab
that
module
constructor
and
I
go
into
a
different
realm
and
I
do
new
module,
what
happened
there.
C
A
C
No
referral,
I'm
not
sure,
I'm
not
sure,
that's
the
right
approach
we
can
talk
about.
I
can
think
more
about
it,
but
I
think
that's
so.
Basically,
you
are
opening
the
door
for
anyone
at
any
level
to
create
a
module
that
escapes
the
conditions
of
the
module
that
you
that
you
are
applying
restrictions.
Let
me
let
me
do
let
me
do
it
this
way.
So
if,
if
I,
if
I
create
a
module
from
source
and
the
source
of
the
module,
is
the
one
doing
new
module
or
calling
import
or
whatever?
C
C
C
No
just
very
simple,
very
simple
forget
about
evaluators
and
everything.
I
have
a
module
that
I
create
from
source
and
in
that
source
I
want
to
be
able
to
tap
into
the
the
global
behavior
without
using
the
reflection
api
want
to
tap
into
the
global
behavior.
How
do
I
do
that
with
the
current
api?
You
do
not
have
the
ability
to
do
that.
C
C
B
C
Options
you
open
the
door
for
that,
then
I
will
be
able
to
construct
any
source
that
automatically
relies
on
the
global
behavior
for
the
source
that
I'm
constructing.
I'm
not
sure
we
want
that.
So
it's
just
that!
That's
my
current
model
like
I.
I
feel
that
that
there
might
be
some
issues
there.
I
don't
I
don't
know
I
haven't
think
much
about
it.
We
never
talk
about
this
particular
point
in
detail,
but
it
feels
to
me
that
there
might
be
some
issue
there.
C
C
Grab
the
sword
from
you
and
I
create
that
module
intense
and
I'm
giving
my
hope
so
any
module
that
you
require.
I
am
the
one
providing
that
to
you.
You
don't
have
any
option
beyond
that
in
the
current
methods
right,
so
you
do
import
you
go
through
me.
You
do
what
you
can
only
do
in
four
because
a
static
one
I
I'll
get
the
no
matter.
One
right.
C
A
new
module
today,
but
you
have
to
provide
a
hook,
so
you
have
to
invent
something
to
do
the
thing
which
most
likely
you
will
go
through
my
import.
Somehow
I
don't
know
you
will
do
import
under
the
hook
for
my
stuff
and
I
grab.
I
I
control
you
now.
If
that
thing
is
optional,
chris
will
be
able
to
create
a
single
line,
module
that
goes
and
does
an
import,
and
it
will
bypass
the
restrictions
that
I
put
onto
you,
because
you
will
go
straight
into
the
global.
C
D
A
B
B
A
Yeah
yeah:
we
can
talk
about
that
at
length.
I
think
the
if
the
idea
is
you're
you're.
What
you're
suggesting
is
that
if
we
have
an
options,
bag
object
that
we
treat
as
a
that
we
treat
as
something
more
analogous
to
a
proxy
handler,
except
we
want
to
capture
all
of
the
handler
behaviors
eagerly
at
the
time
of
the
construction
of
the
module.
In
order
to
not
recapitulate
the
mistakes
of
the
past.