►
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
A
C
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
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
A
A
A
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
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.
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.
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
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
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
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.
A
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
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
F
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.
H
C
C
B
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
A
G
C
B
C
C
C
A
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
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
A
C
F
C
C
A
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.
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
C
A
C
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
A
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
B
C
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
A
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
A
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
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.
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.
F
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
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.