►
Description
The pair programming session from 11/01/2021 on provide/inject pattern in Source Editor extensions architecture
A
Yes,
hello.
Everyone
we're
here
today
at
yet
another
editor
extension
architecture
session,
where
we
are
talking
about
architecture
of
the
source
editor
in
general
and
the
extensions
and
how
these
two
play
together
and
how
to
to
make
them
work
efficiently
and
effectively
for
the
for
us
and
for
the
rest
of
the
team
and
from
one
of
the
not
from
the
very
last
session.
A
The
last
session
was
when
enrique
showed
us
the
his
ideas
about
the
ui
parts
of
the
extensions,
but
the
one
before
that
we
were
talking
about
the
the
architecture
and
we
left
off
with
paul,
providing
the
snippet
but
pawn
not
intended
the
snippet
about
provide
inject,
so
paul,
provided
a
snippet
vote
provide
in
check.
A
So
I
would
hope
us
to
get
into
this
one.
But
there
was
also
the
the
question
in
the
notes
that
I
don't
think
we
have.
We
have
addressed
the
question
from
you
paul
right,
so
the
I've
linked
the
poc
in
the
agenda
so
that
we
have
everything
everything
in
place.
A
The
I've
also
copied
over
the
over
both
of
your
items
file
to
today's
agenda
so
that
we
have
those
and
I'm
wondering
whether
you
would
like
to
just
drive
right
away.
Yeah
cool.
C
I'm
happy
too
yeah,
that's
that
that'd
be
fine
and
I'm
not
sure
what
my
question
was
questioning.
So.
A
I
think
it
was
in
particular
about
methods
like
remove
acts,
math
from
method-
and
I
I
will
be
honest-
I
haven't
looked
into
this
so
we'll
go
through
this
okay.
A
Now,
I'm
I'm
not.
C
A
About
it
really
so,
but
remove
x
from
let's,
let's
just
check,
what's
this
so
remove
acts
from
method
right,
that's
there
is
this
well.
Actually
this
this
question
is
is
really
is
really
nice.
Let
me
just
share
my
screen
for
for
this
very
first
thing,
so
that
I
show
you
how
things
are
wired
together
here
and
then
we'll
switch
to
your
screen
to
for
you
to
drive
us
through
the
provide
inject
okay.
So
let's
get
rid
of
this
thing
and
take
this
one.
A
So
do
you
see
my
screen
now?
Yes,
yeah,
okay,
cool,
so
the
method
remove
x
from
method.
This
is
the
method
in
the
source,
header
core.
So
this
is
related
to
to
the
way
the
extensions
are
organized
in
this
poc.
So
when
we
use
an
extension
when
we
apply
an
extension
to
an
instance
in
order
to
keep
the
proper
registry
of
the
extension,
what
we
do
is
we
store
store
a
couple
of
things
in
addition
to
to
what
is
already
in
the
in
the
source
area
at
the
moment.
A
So,
first
of
all,
we
store
the
extension
itself.
We
store
the
definition
of
the
extension,
not
the
not
the
instance
of
the
class
for
the
extension,
but
the
definition
of
the
extension
so
that
we
could
re-instantiate
it
whenever
we
need
for
other
instances
without
actually
requesting
this.
This
extension
requesting
the
definition
again.
So
there
is
one
registry
for
the
extension
definition
then,
on
the
instance
level,
if
we
take
a
look
here,
so
let's
just
make
it
bigger
yay.
A
So
on
the
this
is
the
header
extension
nope.
So,
on
the
instance
level,
we
have
the
map
with
the
methods.
So
what
this
map
does
when
we
apply
an
extension
to
an
instance,
we
create
this
registry
of
the
methods,
all
the
methods
available
on
this
instance
either
the
instance
itself
or
through
the
extensions,
and
then
we
map
the
extensions
names
that
which
do
define
this
method.
A
So
in
general,
in
most
cases
it
will
be
just
one
to
one
so
one
extent
one
method
name,
one
extension
name,
but
in
cases
where
we
have
several
extensions
introducing
the
same
method
name,
we
will
store
an
array
of
those
extensions.
Why
do
we
need
this?
Because
if
at
some
point
we
want
to
unuse
one
of
the
installed
extensions,
we
want
to
update
our
instance
so
that
it
would
serve
the
same
because
by
uninstalling
extension,
this
doesn't
mean
this
method
doesn't
doesn't
exist
anymore.
It
should
be
provided
from
another
extension
that
is
registered.
A
I
see
yeah
so
then
we
just
we
just
remo
from
this
map.
We
remove
the
name
of
this
extension
that
we
only
use
so
that,
next
time
we
request
this
method,
it
will
be
served
from
another
extension
in
the
stack
so
that
method
that
you
were
asking
about
the
remove
acts
from
method
is.
It
takes
the
method
that
what
to
analyze
an
extension
name,
which
we
have
to
remove
from
this
from
this.
E
A
No,
no,
no!
We
we
remove
the
method
only
if
the
on
you,
the
extension
we
are
on
using
now,
is
the
last
extension
registered
for
this
method.
Otherwise
we
just
drop
so
technically.
Let
me
just
oh:
oh
I
see
I
see
so
it's
like
it's
the
the
in
the
map.
The
key
is
the
method
name
and
the
value
is
the
array
of
all
the
extension
names
introducing
like
providing
this
method.
F
A
A
It's
just
when
we
register
several
extensions
with
the
same
method.
Name,
it's
just
first
infrastructure.
First
out,
so
we
do
not
interact
with
all
the
previous
extensions
providing
the
same
method.
We
just
call
out
the
method
from
the
last
extension
providing
this
method
so
that.
C
F
Well,
I
mean
it
finished
my
point:
a
preferable
behavior
until
we
do
something
better
either
it
wraps
the
previous.
You
know
declared
extension
in
order
or
something
more
clever,
that
it
doesn't
just
stomp
a
previous
extension
and
likely
break.
It
is
to
just
fail
like
say
no,
you
cannot
have
these
two
extensions
active
at
the
same
time,
which
attempt
to
override
the
same
method,
because
otherwise
it's
going
to
be
like
an
unexpected
failure.
F
A
There's
a
problem
with
failing
hard,
so
the
the
extensions
author,
the
extension
authors.
They
should
not
keep
in
mind
all
of
the
possible
extension
methods
coming
from
other
extensions
right.
So
you
don't.
A
A
A
It
that
means
that
you
use
it,
but
that
means
that
the
the
end
user
won't
be
able
to
use
both
of
extensions.
Yes,
that's.
F
Fine
and
I'm
saying
that
is
a
much
more
preferable
behavior
for
the
end
user,
the
first
time
they
attempt
to
start
the
application
or
load
the
page,
with
a
configuration
of
two
conflicting
extensions
that
it
blows
up
with
a
nice,
meaningful
error
message,
saying
sorry,
extension
foo
attempts
to
implement
the
same
method
baz
as
extension
bar.
You
cannot
use
them
at
the
same
time
as
opposed
to
it
happily
lets
them.
Do
that
and
then
extension
bar
just
breaks,
because
food
stomped
on
its
implementation
of
method
baths.
F
A
All
my
with
all
my
tasks,
I
seriously
cannot
find
an
example
where
this
scenario
would
so
technically
we
are
overriding
the
like.
A
The
the
only
the
only
case
where,
where
things
might
go
wrong
is
when
we
have
two
extensions,
providing
the
same
with
the
same
method
and
so,
let's
say,
extension,
a
and
extension
b,
so
we
first
use
extension
a
and
then
extension
b,
so
both
of
those
who
have
the
same
method
and
following
the
logic
that
is
implemented
at
the
moment,
the
the
extension
b
pro
will
be
the
the
source
for
this
method
right.
So
the
functionality
of
this
map
of
the
same
method,
in
extension,
a
will,
be
completely
ignored.
A
So
the
only
the
only
moment
when
things
might
go
wrong
is
when,
within
the
extension
a
we,
we
extension
a
provides
a
some
unique
method
that
is
not
overridden
by
the
b.
So
a
provides
this
unique
method
that
talks
to
that
method,
in
extension
a
and
expects
some
signature
of
this
method.
However,
if
this
happens,
we
will
be
serving
the
method
from
the
extension
b
and
the
signature
might
not
necessarily
be
the
same.
A
So
that's
that's
the
only
collision
that
might
happen
here,
but
it
at
least
thinks
will
work
for
the
end
user
and
we
will
not
sort
of
put
the
blame
on
the
end
user.
That
that
is
not
correct.
From
from
my
point
of
view
where
we
put
the
blame
on
the
end
user,
because
users
user
needs
both
functionalities
of
both
extensions.
But
then
they
cannot
use
them
together
because
because
like
because
the
authors
of
the
extensions
didn't
think
about
this.
F
A
F
A
So
this
is
the
public
api
of
of
an
office
extension,
so
that
array,
like
not
yeah
the
array
that
is
the
value
within
the
map
of
the
methods,
will
contain.
These
names
like
get
through
like
the
values,
will
be
get
full
basic
basic
with
private
problem.
The
methods
this
particular
extension
provided
for
this.
Yes,
yes,
these
are
the
methods,
if
it
happens,
so
that
an
extension
provides
a
method
that
collides
with
the
native
method
name
of
monaco
instance.
A
So
they
both
will
be
ignored
and
native
monaco
method
will
be
served.
C
We
may
not
have
any
issues
right
now,
but
that's
with
the
goal
of
trying
to
find
a
way
to
provide
and
eject
the
methods
and
names
facing
them.
So
that
me,
as
an
extension
provider.
I
have
a
very
clear
public
api
I'm
serving
and
that
public
api
is
name
spaced
under
something
so
that
you're
not
going
to
collide
in
my
private
methods.
My
private
api,
I
shouldn't
ever
get
mixed
in
or
messed
up,
and
I
should
try
to
be
able
to
call
it
whatever.
I
can.
C
F
F
A
We
need
to
be
able
to
because
we
need
to
be
able
to
unuse
the
extensions
we
have
to
be
able
to
drop
the
extension
and
the
still
so
technically
imagine
the
situation.
You
have
three
extensions
applied
to
an
instance
and
you
want
to
unuse
the
second
extension.
So
this
means
that
we
drop
the
second
extension,
but
the
methods
provided
by
first
and
the
third
extension
should
still
work.
So
that's
why
we
just
drop
the
second
extensions
in
in
the
graceful
way,
so
that.
F
A
That's
the
question
I
have,
I'm
sorry:
have
we
all
looked
in
the
into
the
poc,
because
it's
really
hard
to
discuss
poc
without
actually
understanding
what
is
going
on
in
the
poc
right?
That's
the
problem.
I
think
that
we
we
have
to
be.
We
have
to
all
be
on
the
same
page,
knowing
what
is
going
on
there
in
order
to
understand
the
limitations
of
the
current
solution,
but.
F
Insight
comes
from
somebody
with
no
context
of
the
problem
saying
this
makes
no
sense
to
me,
but
so
being
able
to
state
yet
still
be
able
to
state
the
problem
clearly,
and
if,
if
you
are
fully
understanding
of
the
implementation,
as
the
expert
role
in
in
the
mob
repair,
you
should
be
able
to
coherently
explain
in
a
way
that
a
beginner
could
understand
what
the
problem
is.
So
like
I'll,
try
to
once
again
clearly
state.
What's
confusing
me,
you
said:
there's
an
array
of
some
methods
that
need
to
be
registered
and
then
registered.
Okay,.
A
F
A
F
You
have
to
remember
it:
okay,
so
like
I'm,
assuming
that
the
thing
you're
removing
like
since
this
is
an
extension,
is
a
function
defined
somewhere
right
and
to
me
it's
like
okay,
if
that
function
is
defined
somewhere
and
you
have
to
remove
it
when
you
unuse
the
extension
that
implies
it's
in
some
shared
state
to
me
that
could
possibly
conflict
through
another
extension.
Otherwise,
if
it's
not
possible
to
conflict,
why
would
you
you
need
to
to
clean
it
up?
I
guess
that's
what
I'm
missing
about
this,
but
tell
me
if
I'm
completely
so.
A
The
the
thing
is
that
we,
so
we
do
not
like
this.
This
solution
is
totally
based
on
on
the
on
the
proxy
right,
so
we
proxy
between
the
native
monaco
instance
and
all
the
extensions
registered
for
this
instance.
Those
extensions.
A
As
I
said
we
have
the
definitions
stored
in
the
in
the
global
editor
and
then
we
on
the
instance
level.
A
We
have
that
map
with
the
with
the
methods,
so
the
methods
like
if
we
look
at
this
map,
where
is
it
at
this
methods
map
so
technically,
just
so
so
that
we,
let
me
just
get
this
so
oh
here
we
have
it
a
bit
different,
but
technically
it's
going
to
be,
for
example,
if
we
take
this,
this
extension
that
we
have
here
the
let's
say,
basic
with
private
prop
and
the
extension
was
the
extension
name-
was
ioc
extension,
okay,
so
just
so
that
we
have
the
the
example
here
so.
A
A
We
simply
store
the
strings
for
every
method
introduced
by
every
extension.
We
just
store
it
as
the
strings
method
name
and
the
the
extension
name.
So
when
we
want
and
the
the
main
point
for
this,
as
I
said,
is
the
to
be
able
to
drop
the
things
so
before
we
get
there
like
when
we
call
a
method
here
is
the
here
is
the
proxy.
A
A
You
know
that's
that
that
part,
that
part
was
correct.
I
mean
if
we.
F
So
I'm
saying
it
would
be
better
if,
rather
than
you
know
the
get
zero
it's
like,
rather
than
even
having
an
array
at
the
time
you
attempted
to
define
basic
with
private
prop
or
an
irc
extension.
You
heart,
you
fail
fast,
and
you
say
sorry:
you
cannot
register
ioc
extension
because
ioc
extension
2
has
already
registered
basic
with
private.
Prop.
Please
contact
the
author,
one
of
them
to
change
the
name
of
their
extension
name
or
their
method.
C
And
yeah,
I
think
the
we
want
to
avoid
unexpected
runtime
errors
and
yes
and
failing
early
as
possible,
helps.
C
C
These
extensions
weren't
working,
but
it
can
be
a
challenge.
I
think,
if,
if
I
have,
if
we
do
this
at
the
method
level,
that's
going
to
be
a
challenge
of,
because
I
have
to
know
what
are
all
the
methods
everyone
else
is
using,
and
I,
where,
on
the
snippet
and
then
some
of
the
discussion
about
doing,
provide
inject,
I
think
and
something
here
too,
I'm
really
really
interested
in.
We
want
extensions
to
have
a
clear
public
api
and
a
clear
private
api.
They
need
to
be
able
to
create
their.
A
A
Will
go
nothing
nothing
outside
of
this,
so
if
the
method
is
not
registered
in
methods,
it's
not
constituting
the
public
api
hands,
it's
not
going
to
be
registered
and
it's
going
to
be
considered
like
for
the
class.
It's
not.
It
might
not
be
considered
as
the
private
ma
private
method,
but
for
the
purpose
of
the
extension
it
will
be
considered
private
and
we
won't
get
to
it
if
it
makes
sense.
C
Yeah
and
in
a
side
note
if,
if
an
extension
needs
to
keep
track-
and
I
see
we're
doing
that-
like
this
dot
foo
in
here
or
yeah,
so
extension
needs
to
keep
track
if
it
does
of
its
own
state
some,
then
it's
going
to
manage
on
its
own
can
an
extension.
A
Not
the
instance,
the
instance
will
be
used
for
one
ins
like
the
extension
instance
is
one
per
editor
instance.
Technically.
E
So
it's
not
gonna.
C
A
That
that's
why
I
I
said,
like
I
mentioned
this
separately,
that
we
did
not
store
the
the
extension
instance.
We
did
not
create
new
some,
like
extension
class,
but
we
store
the
definition
so
that
we
avoid
the
unnecessary
round
for
to
fetch
the
extension.
If
another
extension
needs
this,
but
we
do
not.
We
did
not
bootstrap
that
extension
yeah.
We
just
store
the
definition
so
that
it's
it's
just
faster
here
faster
when
another
extension
needs
it.
Yeah
yeah.
C
And
that-
and
that
makes
sense
yeah,
so
I
think
what
I
think
would
be
really
cool
here.
This
is
what
I
was
suggesting
with.
C
Because
we
have
a
requirement,
we
see
down
the
field
down
the
line
that
an
extension
may
require
some
other
methods
like
this
new
extension
of
you
know.
Top
bar
may
require
some
base
panels,
extension
and
that's
providing
some
stuff,
and
so
very
much
inspired
from
provide,
injects
or
like
dependency
injection
around
angularjs.
C
What,
if
my
extension,
if
it
was
going
to
use
methods
it
needs
from
elsewhere,
it
would
say
I
require
these
namespaces
and
if
I
am
providing
public
methods,
I'm
also
going
to
say
these
public
methods
are
under
this
namespace
and
the
goal
of
it
is
very
similarly
what
we
can
do
with
what
chad
was
talking
about.
We
can,
we
can
say
we
can
say
something
to
the
effect
of
you
know:
hey.
C
C
We
can't
do
this
again
and
that's
gonna
be
a
lot
easier
to
keep
track
of
than
seeing
what
methods
have
been
used
just
seeing
like
if
something
happens,
to
be
doing
something
public
what
namespaces
are
being
used
and
then
these
individual
methods,
rather
than
looking
at
just
this
dot
whatever
I
can
actually
res,
I
can
receive
the
injection
of
values
as
one
of
my
arguments
or
we
could
do.
We
could
mix
it
into
this
dot,
but
I
want
to
really
try
to
avoid
changing
this
dot.
I
was
thinking
we
could
have
as
function.
C
Parameters
like
the
first
parameter
is
going
to
be
injection
stuff.
I
can,
I
can
look,
I
can
pull
from
the
whole
goal
of.
It
is
completely
avoiding
any
kind
of
name
collision
issues
that
could
pop
up
and
being
really
explicit
with
with.
This
is
what
I
depend
on,
and
this
is
what
I
expose.
F
C
Yeah,
but
so
with
view,
though
it
would
be
very
similar.
C
C
You
don't
want
to
use
it
too
much
with
view,
because
things
do
mix
in
down
the
chain
so
like
what
I
could
be
injecting
some
component.
That's
actually
expecting
a
provide
from
a
root
component,
but
then
somewhere
in
the
middle.
Another
component
is
providing
the
same
name
to
thing
and
that
could
cause
issues
and
and
view
as
they
run
into
the
same
problem
with
provide
inject.
This
is
trying
to
do
provide
inject
with
namespaces.
A
I'm
I
just
I
just
expected
us
to
take
the
to
take
your
snippets
or,
like
suggestion
of
your
snippet,
and
maybe
maybe
just
I
don't.
H
C
C
Here,
there's
a
method
that
we're
exposing
as
putting
by
putting
it
in
the
methods
function,
but
it
appears
to
only
ever
be
called
by
us
in
this
extension.
Okay,
so
would
I
be
able
to
move
this
out
and
we're
all
still
good
yeah
yeah?
C
B
Yeah,
what's
wrong
with
you?
Oh
it's
because
it's!
What
is
wrong
with
you
expected
that
oh
freaking,
okay
and
this.
C
This
can
I
replace
instance
with
this.
Is
that
that's
like
I,
I
think
so,
okay,
all
right,
so
I
and
we
could
test
this
out
later
or
whatever,
but
yeah.
That
would
be
one
goal
of
this.
It's
like
only
things
that
are
called
outside
of
myself.
Let's
put
those
in
everything
else
should
be
able
to
be
put
outside
of
there,
which
would
be
really
sweet,
and
I
love
I.
I
love
marking
these
with
leading
underscores,
but
for
some
reason
our
our
lantern
is
not
like.
Yes,
that's.
C
C
A
G
C
I
disable
the
role
for
the
whole
file,
so
then
what
I
was
thinking
would
be
cool
is
having
maybe
somewhere
on
setup.
Maybe
it's
a
separate
method
but
having
something
that
is
like
we
are
going
to
and
jax.
This
is
what
I
depend
on
and
I
need
I
don't
know
I
I
need
panels
and
gosh
freaking.
Okay,.
C
And
then,
when
I
yeah
and
then
maybe
I
could
do
something
like
provides
return
web
id
or
something
like
that,.
B
C
C
C
Okay.
So
then,
when
I'm
using
the
extension,
the
whole
goal
is:
okay.
Okay,
okay,
all
right,
editor
extension.
A
Instance,
so,
like
the
extension
now
as
you
as
you
can
see,
we
are
passing
the
extension,
the
extension
a
when
we
initialize
an
extension
extension
in
the
constructor
is
the
object
that
contains
the
definition
and
the
setup
options,
so
why
these
are
split.
I've
already
mentioned.
A
We
want
to
be
able
to
store
definition
without
actually
getting
to
this
to
the
extension
module
several
times.
So
definition
is
separate
and
then
setup
options
is,
are
the
options
that
we
want.
Our
want
to
set
up
our
extension
with,
so
those
are
passed
into
the
extensions
constructor
when
we,
when
we
call
new
on
that
extension,.
C
A
C
A
Get
is
the
is
the
property
like
technically
technically
together
to
return
the
the
thing
registered,
the
public,
the
thing
from
the
public
api
of
this
method,
because
we
are
storing
it
in
this
methods.
Object.
So
so
that's
that's
why
we
need
some
extra
layer
to
get
clear.
C
So
here
we
extension
register
these
okay.
A
This
is
the
store
extension
method
is
where
we
actually
fetch
those
method,
names
from
the
methods,
object
and
just
toss
them.
C
Okay,
so
what
the
providing
inject
is
going
to
has
the
potential
to
dramatically
change,
how
we
are
implicitly
mixing
in
with
proxies
and
because
what
would
be
really
sweet
is
like
here.
I
am
providing
a
set
of
methods
that
are
going
to
fall
under
here
and
if
I
then
ever
need
those
I
should
be
able
to
see
like
I
was
anticipating
something
like
I
can
require
from
my
arguments,
something
like.
C
Oh,
I
need
the
web
id
extension,
I'm
gonna,
you
know
update
the
web
ide
to
do
you
know
we're
gonna
do
food
here
or
something
like
that,
and
so
rather
than
needing
to,
rather
than
needing
to
manage
this
this
proxy
and
every
time
I
request
something
you
know
looking
through
my
list
of
things
and
getting
it
to
the
right
place
and
stuff
like
that.
C
I
am
just
managing
these.
Are
these
are
different
buckets
of
functions
and.
C
A
I'm
sorry
in
this
particular
example:
the
technically
we
will
be
able
to
use
the
web
id
instead
of
this
like
web
id
dot
instead
of
this
dot
right.
So
that's
that's
the
point.
A
Of
of
this,
of
this
module
or
whatever
it
is
right.
C
F
Is
to
have
them
wrap
each
other
and
just
the
last
one
wraps
any
previous
one.
That
will
that's
more
complex,
but
it
allows
like
people
to
basically
extend
the
behavior
of
it
another
extension
or
fix
a
bug
in
it.
If
you
know
yeah
and
the
author
is
unresponsive,
if
this
is
like
it
gets
in
wider
use,.
C
I
think
that's
helpful,
for
I
think
that
could
be
helpful.
I'm
just
want
to
lean
towards
being
like
as
explicit
and
non.
C
And
if
it
seems
like
that's
helpful,
then
if
it
seems
like
that
kind
of
thing
would
be
helpful,
then
let's,
let's
let's
figure
that
out,
but
I
know
we're
running
close
to
you
to
the
end
of
our
I'm.
C
A
Think
this
would
be.
This
would
be
super
cool,
so
just
just
to
make
sure
so
with
providing
jet.
What
we
try
to
achieve
is
clearly
set
the
dependencies
between
the
the
extensions
and
be
able
to
completely
decouple
the
public
public
api
of
an
extension
from
technical
from
the
extension
itself.
E
And
yeah,
that's
that's
very
much
the
goal
and
but
in
this
particular
case,
if
we
would.
C
Yes,
so
I
would
for
here
my
ideal.
Api
would
be
that
I
can
just
call
so
here
if
I'm
in
update.defu
yeah,
this
isn't
a
part
of
it.
Yes,
I
should
be
able
to
totally
do
this
that
updated
view.
That
would
be
amazing.
I
would
love
that
I
would
also
love
if
one
of
my
public
methods
needs
to
call
another
one
of
my
public
profits.
If
gosh,
I'm
sure
we
have
one.
B
Do
we
have
it
maybe
or
maybe
not.
A
So
if
we,
if
we
need
to
call
like
okay
here.
C
Let's
say
let's
say
here:
I
need
to
call
update
dimensions.
I
would
love
to
be
able
to
just
do.
This.
update
dimensions
like
that
would
be
amazing,
but
now
I'm
and
now
that
I'm
thinking
about
it,
I
realize
these
methods
aren't
really
in
next
to
each
other
and
if
we
are
removing,
if
we
are
a
namespace,
putting
all
these
methods
under
a
namespace,
how
do
we
do
that,
and
I
have
some
ideas
about
it.
The.
A
Thing
is
that
those
those
things
do
were
the
work
in
the
current
modulation
right,
so
you
are
able
to
do
this
dot
update
the
view
and
you
will
get
to
your
public
to
the
public
method
defined
in
this.
In
this
extension,.
C
Yeah
and
that's
the
goal-
yes,
so
that's
definitely
we
want
to
preserve
that.
That's
really
sweet
yeah,
but
then
to
up
to
reference
methods
that
aren't
here
right.
I
would
really
like
to.
I
don't
want
it
to
be
in
this
I'd
like
to.
A
Be
very
decorative
of
what
so
it's
the
the
technically
the
the
main
application
area
is
actually
to
set
up
the
dependencies
and
be
able
to
to
allow
extensions
to
talk
to
each
other
without
like
without
yelling
at
each
other
right.
So
hopefully,.
C
C
And-
and
I
think
it's
gonna
be
really
cool
too
even
outside
of
even
outside
of
extensions,
I
think
it
could
be
really
cool
too
for
me
to
be
here,
because
this
create
model
thing
is
a
web
ide
thing:
it's
not
a
monoco,
editor
thing
right
now
and
so
it'd
be
really
cool
to
say
we're
going
to
do
the
webi,
we're
like
we're
doing
this
from
the
web
id
name
space,
no
wait.
C
Oh
you're
right,
I
forgot
where
it
was.
Oh,
no,
oh,
no,
no
you're!
Right!
Yes,
sorry!
I
went
to
the
wrong
place.
I
meant
create
yes,
yes,
and
that
would
be
really
sweet
to
be
because
this
clearly-
and
you
saw
me
I'm
confused
already-
I
don't
know
what
this
is
or
where
it's
coming
from
it'd
be
really
cool.
C
If
it
was
like
web
ice,
I
wish
it
was
called,
oh,
whereby
it'd
be
really
cool
if
it
was
just
super
explicit
like
oh,
this
is
a
web
ide
thing
like
this
is
for
that
specific
extension
and
I
think
there's
a
lot
of
value
in
that
and
we
don't
have,
and
it's
gonna
solve
a
lot
of
the
problems.
C
Chad
was
already
worried
about
of
name
collision
stuff,
so
this
is
provide
inject
plus
name
spacing,
and
I
think
the
key
change
is
going
to
be
over
wherever
we
call
wherever
we
call
methods
there
might
be
other
more
holistic
ways
to
to
reorganize
this,
but
whatever
we
call
methods
right
online,
yeah,
yeah,
yeah,
yes,.
C
A
Yeah,
technically
in
the
methods
we
instead
of
yeah,
instead
of
like
storing
the
the
extension
name,
we
will
just
store
the
namespace
and
technique.
Essentially
it
will
boil
down
to
exactly
the
same
thing
right.
So
we
just
in
this
array,
we
will
have
the
the
namespaces
that
makes
sense
and.
F
A
One
one
thing
like
just
just
to
to
to
wrap
it
up
when
we
use
an
extension
in
like
in
the
if
we
go
back
to
repo
editor,
for
example-
and
here
we
say
this
editor.web
ide
dot,
the
problem
is
or
like
not
the
problem,
but
the
confusing
part
is
that,
in
order
to
do
this,
you
have
to
know
this
this
namespace
of
the
extension
right.
So
would
it
be?
What
about,
for
example,
be
able
to
to
cut
to
specify
custom
namespace,
for
example,
if
in
this
particular
module?
A
A
C
F
C
Think
is
saying,
is
here
I
could
say
we're
creating
the
extension.
What
I'm,
what
I'm
saying
is:
oh
gosh.
What
is
do
you
see
this?
Oh
wow.
B
C
Where
is
the
web
id
extension?
Where
is
this?
Is
it?
Is
it
in
this
file?
Oh
here
it
is
yes
you're
saying
I
could
do
something
like
namespace.
C
Space,
yes,
yeah
and
then
I'm
going
to
say
web
id
yeah,
so
then
elsewhere
I
know
in
the
same
file.
These
are
there
and
this
works
as
long
as
I'm
the
only
client
of
that
extension,
and
I
think
we
want
to
assume
as
soon
as
something's
public
it's
public
and
out
there
and
anything
could
call
it
and
that's
where
it
would
get
more
challenging.
I
think
yeah.
A
But
I
I
didn't,
I
didn't
mean
to
replace
that
provides,
provides
with
webide.
I
mean
just
to
be
able
to
override
that
what
that
device.
A
This
is,
I
I
mean
on
the
on
the
extension
level
we
have,
we
will
still
do
provides,
it
will
just
be.
We
will
either
provide
web
id
as
it
is
specified
in
the
extension
or
if
it
has
been
passed
to
this
extension.
D
A
F
Where
we
would
the
name
space
registration
like
part
of
the
contract
of
an
extension,
there
would
be
like
a
namespace
function
that
returns
a
string
and
on
registration.
That's
what
would
be
checked
for
conflicts
like
you
cannot
register
two
things
with
the
same
name
space
and
and
we
would
catch.
We
would
still
kind
of.
C
Catch
that
issue
here,
but
the
the
pro
is
that
hey,
it
is
kind
of
cool.
I
get
to
control
the
name
of
this
function.
I'm
gonna
call
within
the
same
file,
that's
kind
of
nice,
but
I
think
because
of
our
goals
with
extensions,
I
don't
want
to
you
don't
want
to
introduce
the
coupling
of.
I
know
this
extension
doesn't
need
this
one
and
that's
a
more
that's
a
more
dangerous
coupling
right,
yeah
yeah.
F
F
E
Don't
know,
I
think
it's
a
good
idea,
though,
but
yeah
I
think,
because
technically
we
can,
since
since
we
are
again,
we
are
doing
dealing
this.
A
On
an
instant
instance
level
right,
so
it's
going
to
be
the
same
user
using
using
both
extensions.
So
if,
if
a
user
custom
provides
to
to
web
id,
this
means
that
they
can
as
simple
as
that
pass.
The
custom
injects
to
the
markdown
extension
right.
If
the
markdown
session
would.
C
That's
really
cool
if
we,
if
we
are
super
explicit
about
this
this
this
is
what
would
be
really
sweet
and
also
to
your
point,
chat
too.
If
I,
if
I
did,
provide
this-
and
this
is
something
that
just
the
extension
itself
can
implement
and
and
it's
nothing
we
really
need
to
worry
about.
But
if
I
didn't
have
something
like
namespace
is
actually
web
ice,
because
I
really
like
that
and
this
one
said
I
depend
on
web
ide.
C
We
should
blow
up
here
like
and,
and
it
would
actually
blow
up
with
a
very
clear
message.
I
depend
on
web
ide
and
I,
as
the
developers
should
know
exactly.
Oh,
I
know
what
the
problem
is
right
away
rather
than
if
we
let
it
just
ambiguously
depend
on
something
and
not
being
able
to
check
it,
and
then
we
run
into
some
esoteric
runtime
error
that
we're
not
sure
where
it
came
from.
That's
the
risk
of
these
things
all
depending
on
a
shared
object
and
the
name
spaces.
C
Allow
us
to
be
really
explicit
with
I
provide
this.
This
is
what
I'm
depending
on,
and
we
can
check
that
at
use
time,
which
is
which,
which
would
be
really
cool.
So
even
if
I
did
implement
something
like
this,
and
this
was
dependent
on
it
because
of
name
spaces
like
we
should
get
some
eager
failures,
which
is.
A
C
And
that'd
be
cool,
I
so
one
one
thing
and
then
yeah
I
know
I
know
I
gotta
hop
off
to
some
other
stuff
and
one
thing
when
we
do
this
and
you're
right,
so
we
could
just
save
the
methods-
okay
here,
some
somewhere
on
use
where
I'm
actually
using
the
thing.
I
guess
it's
here
where
we
have,
where
I'm
registering
some
methods.
C
Okay,
I
actually
want
to
register
a
namespace
and
then
an
object.
So
that's
one,
that's
kind
of
what
I
think
would
be
so
here
I
want
to
register
from
namespace,
which
is
a
string
to
an
object
of
functions.
C
The
one
thing
I
think
we'll
want
to
do
so
that
I
can
all
stuff
like
this
that
update
the
view
from
within
here
and
stuff.
I
think
we'll
want
to
do
something
like
after
calling
methods.
We
want
to
do
something
like
map
values
and
each
one.
I
need
to
do
something
like
fn.bind
to
actually
an
instance
of
that
extension
thing
I
need.
I
need
to
make
sure
I
bind
those
methods
you
know
so
that
when
they're
called
because
it's
a
separate
object,
they're
cool
they're
called
with
the
context
right.
A
That's
that's
that's
handled
by
the
by
the
by
the
proxy.
I
think,
but.
F
C
Yeah
yeah
and
I
think,
and
so
then
I
would
use
something
like
methods
dot.
I
forgot
set
namespace
and
then
my
namespace
methods
or
something
and
yeah,
and
then
that's
so
then,
when
I
am
calling
a
method,
I
am
anticipating,
adding
my
like
a
name
to
some
sort
of
name
space
thing
where
I
can
pull
from
that's
one
idea
for
how
we
can
eject
these
things.
C
F
C
And
I
I
think
the
one
the
one
problem
we're
trying
to
solve
here
is
the
naming,
collisions
and
being
extra
explicit,
but
I
think
there's
definitely
trade-offs
with
it.
F
F
Level.
Okay,
then,
in
that
case
I
do
think
this
case
is
superior
because
then
you're,
eliminating
that
you
know
shared
state
and
coupling
and
the
binding
and
processing,
is
done
well
via
the
bind
method
right
each
extension
level,
and
it
just
goes
away
when
you're
unregistered,
there's
no
common
state
to
worry
about.
C
Yeah,
I
think,
we'll
see
I'm
I'm
down
preparing
on
this
morning.
C
If
dennis,
if
you
want
to,
if
you
want
to,
if
you
want
to
wrestle
with
this
and
see
we'll
see
which
turn
out,
we
can
asynchronously
collaborate
on
it
or
we
can
I'm
also
down
with
just
picking
up
next
week
when
we're
all
together,
we
can
try
to
be
more
get
actually
a
feedback
loop
and
get
see
if
we
can
find
something
that
works.
So
this
was
very
messy,
but
I
think
it
was
oh.
A
It's
it's
it's!
It's
really
really
interesting
to
see
this.
This
is
the
cities
and
I
I
really
like
this
particular
point
of
injecting
the
dependencies
to
other
extensions
so
that
we
have
clear
clear
overview
of
what
comes
from
where
this
this
part.
I
really
like.
C
Cool,
no
thanks,
hey
thanks
thanks
for
the
thanks,
thanks
for
the
work
on
this
and
thanks
for
collaborating
on
it.
This
is
awesome.
Yes,.