►
From YouTube: JupyterLab Weekly Dev Meeting, June 17, 2016
Description
Meeting of the JupyterLab development team.
Meeting Notes: https://jupyter.hackpad.com/JupyterLab-Weekly-Meetings-UUJ3gIQ3iBS
B
Sure
so,
as
a
short
announcement
to
everybody
last
night
we
had
a
short
tutorial
walkthrough
of
the
Jupiter
architecture,
at
least
high-level
parts
of
some
of
the
architecture
and
Jamie
recorded
that
and
it's
available.
So
you
can
watch
that
and
we
also
put
the
the
content
in
a
new
sub
director
of
the
Jupiter
lab
repo,
the
slash
tutorial,
a
subdirectory,
eventually
I
think
that
will
get
move.
Steve
mentioned
moving
it
under
docs
and
redoing
how
our
docs
are
structured.
But
for
now
it's
under
the
slash
tutorial.
I
redirect,
during
the
Jupiter
library
pump.
B
And
we
should
have
to
read
me
to
the
slash
tutorial
as
well:
okay,
let's
just
do
quick
status
updates
and
I
have
a
question
right.
I
was.
B
Ok,
how
about
quick
status
updates
and
I
have
a
design
question
for
a
nice,
and
you
have
questions
yeah,
husband,
Steve.
You
want
to
go
first,
then
Darren.
E
So
we've
been
refactoring
the
cells
to
use
a
pattern
that
accepts
a
an
option
of
interface
that
has
in
it
e
the
functions
that
will
generate
so
much
that
go
inside
I
fell
because
that
way,
it
will
give
you
a
few
things.
One
of
the
things
that
it
gives
you
is
that
warmth
always
need
a
sub
class
based
on
budget
that
you
might
be
able
to
get
away
with
Justin
for
cussing
in
different
options.
If
you
want
a
different
kind
of
cell
and
it
lowers
the
barrier
for
customization.
E
Instantiating
with
a
model
or
adding
the
model
attribute
after
instantiation,
what
we're
still
sorting
that
out,
but
we
want
to
be
able
to
change
the
model
up
until
this
point.
L
models
have
not
been
able
to
be
changed
because
they
were
private
and
you
only
passed
them
in
upon
station.
But
if
we
allow
you
to
change
it,
it
means
that
we
can
keep
things
in
the
Dom
and
replace
what's
inside
as
an
optimization
there,
there
can
be
scenarios
where
you
won't
want
to
say,
throw
out
a
whole
notebook
right.
E
You
might
not
want
to
react
and
fancy
ate
the
whole
thing.
If
you
have
even.
D
E
The
notebook
on
the
screen
to
switch
kernels
was
a
mostly
empty
notebook.
It'll
still
be
fast
and
more
efficient,
just
switch
models,
and
so,
if
we
can
from
every
from
everything
from
the
notebook
down
to
its
constituent
parts,
allow
you
to
change
models,
then
you
can
keep
things
in
the
DOM
and
only
really
swap
things
out
in
memories,
and
so
one
one
side
effect
of
that
has
been
that
we
won't
be
able
to
both
pass
in
the
model
on
instantiation
and
also
make
it
swappable,
because
the
only
way
you
that
involves
doing
an
async
operation.
E
But
it's
difficult
to
reason
about
that.
So
we're
probably
going
to
remove
the
ability
to
change
to
pass
in
the
model
upon
Association
and
only
allow
you
to
set
it
as
an
attribute
after
you,
instantiate
it
and
I.
Think
Chris
did
some
research
into
listen.
It
turns
out
that
PT
has
a
similar
way
of
instantiating
its
widgets,
where
you
give.
A
E
B
So
this
reminds
me
I
mean
we're
removing
closer
and
closer
to
a
reactive
type
of
work
flow
where
the
data
is
supreme.
It
that's
not
a
bad
thing.
I
think
how
are
we
handling
a
different
cell
types?
I
mean
clearly
for
trying
to
do
optimizations
we're
keeping
things
in
the
Dom
we're
moving
closer
to
a
virtual
rendering
type
of
thing
where
it
would
be
easier
to
to
take
care
of
that
sort
of
optimization
layer.
It'll,
add
a
lower
level
than
what
the
programmers
interacting
at.
But
you
know
the
models
can
be
different
types,
yeah.
E
All
they
really
need
to
do
is
to
have
just
like
they
already
have
on
on
update
request,
so
also
have
on
model
change,
and
they
could
do
whatever.
Then
you
can
do
to
initialize
once
a
new
model
comes
in
and
if
they
themselves
have
children,
so,
for
example,
the
code
so
with
it
might
then
say.
Okay,
what
I
want
to
do
is
take
this
model
output
and
swap
it
for
the
outputs
that
my
output
area
had
before
so
each
of
them.
D
Not
suggesting
that
this
is
more
of
you've
got
a
notebook
widget
on
the
page
and
you'd
like
to
switch
it
out
for
to
a
completely
different
model,
different
file,
even
but
you're,
going
to
reuse
as
many
of
those
sub
components.
As
you
can
in
that
process,
and
the.
D
D
Reason
for
moving
the
model
out
of
the
constructor
is
that
basically,
every
method
in
javascript
is
a
virtual
method
and
you
shouldn't
be
calling
virtual
methods
from
your
constructor.
So,
for
example,
anything
that
you
wanted
to
do
on
the
creation
of
a
model.
If
that
was
override
it
by
a
subclass,
then
that
subclass
would
not
be
fully
initialized
when
you're
calling
that
function.
So
any
anything
that
would
have
been
in
in
that
subclasses
constructor
would
not
have
been
called
yet.
So
you
might,
you
have
uninitialized
state.
So
that's
that's
a
real
reason
to
do.
B
It
as
well
well
I
mean
those
are
two
issues.
I
think
one
is
whether
we
want
the
model
to
be
replaceable,
but
once
you
have
the
model
replaceable,
then
you'll
have
a
bunch
of
state
that
you
need
to
rebuild
whenever
the
models
replace,
and
then
you
can't
do
that
synchronously
and
the
constructor,
which
is
I,
think
what
he's
doing
with
the
postmasters
he's
doing
it
asynchronously
and
then
the
constructor
that
those
are
two
separate
issues
right.
D
Right
and
yeah
that
is
correct
about
any
place
model.
The
problem
with
doing
it
asynchronously
is
that
you
then
have
to
as
a
person
writing
the
code
you
have
to
realize
it.
Oh
I
have
to
wait
for
an
animation
frame
in
order
for
this
to
actually
take
place
versus
just
assuming
it's
taking
place.
Synchronously
yeah.
B
Even
when
more
so
again,
what's
the
use
case
for
being
able
to
replace
the
model
if
we're
swapping
out
an
entire
notebook
model,
as
I
cain't
using
a
same
notebook
widget
for
a
different
file,
it
seems
much
simpler
to
describe
the
notebook
widget
and
and
pull
up
a
new
notebook
which
it
if
it
really
is
representing
a
different
file.
Well,.
E
D
E
It's
a
lot
like
the
diverse
build
on
you
thinking
of
but
it'll
be
it'll,
be
really
sort
of
cheap
to
build
it,
and
we
gain
gained
a
lot
without
having
to
do
much
extra
soft
because
all
were
really
doing
is
taking
some
code
that
we
already
had
in
our
constructor
and
we're
just
leaving
it
to
a
different
function
called
on
model
changed.
The
change
in
lines
of
code
is
virtually
nil,
but
the
benefit
that
we
get
is
actually
fairly
substantial
and.
E
For
a
subtle,
depending
on
what
the
capabilities
of
your
children
are
so
right
now
the
output
area
didn't
support
switching
output,
so
what
I
was
doing
was
just
throwing
it
out
and
and
creating
a
new
one,
because
that's
what
I
had
available,
but
now
with
this
new
Kia
that
please
put
in,
we
can
change
that
to
a
more
subtle
behavior.
But
it's
not
it's
not
particularly
difficult
to
reason
about
once
the
pattern
is
established.
E
B
E
B
E
B
D
Widget
workflow.
This
would
be
if
someone
wanted
to
use
this
class
in
a
different
way,
where
the,
where
they're,
keeping
this
cache
and
swapping
out
things.
If
you
had
like
you,
know
an
OPA
preview
widget
that
wasn't
part
of
the
for
some
reason:
wasn't
it
wasn't
even
in
Jupiter
lab
it's
just
an
OPA
preview
widget
and
you
want
to
be
able
to
swap
out
the
file
contents.
You
just
keep
that
widget
on
the
page
and
swap
out
its
model
yeah.
D
So
this
isn't
necessarily
a
Jupiter
lad
application,
but
it's
something
that
could
be
done
with
this
class
for
a
minimal
extra
effort
and
and
right
now,
actually
on
the
notebook
I
just
put
a
to
do.
Maybe
you
might
might
want
to
optimize
the
cells,
but
right
now
it
just
clears
them,
so
it
doesn't
reuse
the
underlying
cells,
but
that
that
could
later
be
added
to
support
these
type
of
use.
Cases
I.
B
Can
imagine
if
you
just
go
all
the
way
I
mean
we're
going
halfway
to
a
reactive
type
solution
where,
where
is
a
lot
of
the
optimization,
is
taking
care
of
resin,
taking
taking
a
Dom
structure
and
replacing
the
content
of
it
and
then
intelligent
leary
rendering?
What's
what's
in
the
dumb,
it's
exactly
the
the
value-add
from
her
yet
but.
C
C
Like
a
different
file
or
like
there's
some
deep
semantic,
meaning
to
this,
it's
not
just
rendering
optimization
like
me,
I
could
imagine
us
using
this
when
we,
when
a
user
clears
output,
we
just
replace
all
the
output
models
by
new
empty
output
models,
but
that's
I,
don't
know
I
I
do
that
is
very
different
from
from
every
time
any
model
changes
to
resetting
the
models
and
probably
like
I'm,
not
I,
don't
think
we
should
do
that
and
I
don't
think
we
should
start
to
use
this
capability
in
that
way.
I.
B
Forget
I
mean
so
again
react
took
it
to
the
extreme
where
they
say
every
time
anything
changes
we're
giving
you
a
completely
new
model,
but
you
have
fast
ways
of
determining
what
changed.
What
didn't
change
in
your
model,
whereas
we're
doing
that
bookkeeping
by
hand
and
I'm
not
saying
that,
like
four
output
areas,
where
you
have
a
cell,
that's
constantly
having
output,
that's
changing!
You
know
the
optimization
of
keeping
that
keeping
the
Dom
there
and
and
and
reusing
the
Dom
elements
that
are
there.
B
But
it
feels
like
we're
introducing
a
lot
of
complexity
but
relatively
to
the
to
the
current
thinking
of
there's
a
model
and
it's
static
and
it's
not
static
but
its
permanent.
Its
final,
you
know
it's
it's
what
the
widget
represents,
and
maybe
the
point
is
to
support
use
cases
that
are
out
there
that
we
haven't
considered
yet.
But
but
then
you
could
say
well,
if
we're
going
to
go
halfway
to
the
solution
of
trying
to
reuse,
widgets
and
stuff
like
that,
I
mean
maybe
the
people
that
would
want
to
do.
B
E
Have
accepted
sorry
I
was
just
going
to
comment
that
what
we
currently
have
basically
says
in
fancy
with
a
model,
and
we
expose
the
model
as
a
public
attribute
that
you
can
get
and
if
you
try
to
set
it
throws
an
error
so
really
from
an
end
user,
not
an
end
user
and
developer
point
of
view.
All
that's
really
changed
is
that
they
could
both
get
and
sent
that
attributes.
They
don't
have
to
really
think
about
what
else
is
very
different.
E
D
E
Gonna
blow
up
anymore,
I
kind
of
think
that
actually
it's
often
counterintuitive
when
we
tried
to
gains
an
attribute,
and
it
throws
an
error
now,
if
you
try
to
change
that
attribute
it
just
works.
That
actually
seems
more
intuitive
for
JavaScript
developers.
From
your
experience
normally
is
that
changing
an
attribute
should
work
and
real
tons
of
reading
indicates.
E
B
B
So
so
that's
not
an
issue,
but
that
was
when
I
sing
it
you
get
with
read-only
yeah,
but
but
the
the
other
thing
I
mean
we're
already
seeing
the
complexities
introducing
in
our
constructor,
because
once
you
can
change
the
model.
Okay,
now
you
might
have
side
effects
okay.
Well,
we
can't
call
those
side
effects
from
within
the
constructor,
so
we
have
to
do
it
asynchronously
or
some
other
way.
Ford
well,.
D
B
Methods
right
so
so
now
we're
now
we're
saying
for
the
user
perspective,
you
don't
set
the
model
in
the
constructor.
You
have
to
set
it
afterwards,
so
you
can
have
a
widget
with
a
null
model,
and
now
you
have
to
now
follow
your
methods
have
to
be
aware
that
the
model
could
be
null
and
check.
For
that
instance,
event.
So
I
mean
there
is
a
lot
of
extra
complexity
on
the
developer
side,
not
necessarily
on
the
user
side.
If
I'm
saying.
D
We
have
to
take
that
period
because
we
were
faking
our
way
out
of
it
before,
but
it
was.
It
was
a
ticking
time
bomb.
So
we've
acknowledged
that
that
you
can't
do
it
in
the
constructor.
It's
just
a
matter.
How
do
we
handle
that
fact
we
can
make
the
we
can
make
the
model
right
once
like
we
have
the
layout
in
the
phosphor.
Widget
is
right
once
and
then
you
can't
change
it
again.
D
It
forces
that
on
that,
would
that
would
throw
out
the
the
whole
the
idea
that
we're
moving
toward
react
in
some
way
and
I'm
fine
with
that
it
was
just.
We
could
make
an
optimization.
We
were
going
to
do
it,
but
if
it's
going
to
bring
up
all
these
other
questions,
I
say:
don't
even
do
it.
Just
it's
a
static
thing.
You
could
set
one
yeah.
C
B
C
A
little
worried
I'm,
obviously
our
models
are
are
designed
to
be
mutable
and
I'm.
A
little
worried
that
it
will
run
into
weird
situations
where
someone
will
have
a
model
and
start
mutating
state
on
it,
and
then
someone
else
will
replace
the
model
and
all
of
a
sudden.
The
model
that
they're
mutating
is
not
the
model
that
sucked
up
to
the
view
and
I
over.
C
B
C
I'm
sorry
I'm
worried
about
the
the
problems
that
come
along
with
references
to
the
mutable
state
and
being
able
to
swap
it
out.
That's:
okay,
no
I'm
fine
with
us
initializing
the
model
after
the
constructor
I
think
from
an
API
perspective
that
cleans
it
up
a
lot.
I'm
I'm
nervous
about
us
sort
of
always
allowing
them
to
be
replaced
in
it,
emo
that
that
I'm,
not
sure
that
makes
sense
that
may
cause
more
problems
than
we
want.
Okay,.
E
E
It
so
you
only
said
it
once
that's
totally
fine
and
then,
if
we
find
a
use
case
that
more
compelling
than
the
ones
we've
come
up
with
so
far,
we
can
then
make
it
settable.
That
will
not
be.
That
will
be
an
API
change
that
won't
affect
anyone,
because
it'll
it'll
be
backward
compatible.
So
that's
totally
fine,
but
we
do
need
to
take
it
out
of
the
constructor.
That
was
how
we
got.
B
E
B
D
Is
it
the
widget
would
not
be
initialized
and
based
on
the
state
of
the
model
that's
passed
to
it?
That
would
be
fine
in
the
mall.
All
work
guaranteed
to
be
uninitialized
when
you
handed
it
to
the
widget
and
then
you
initialize
it,
but
if
you
hand
an
initialize
model
to
the
widget,
then
the
widget
needs
to
respond
to
the
state
of
the
model
yeah,
and
you
can.
D
B
D
A
my
first,
my
first
attempt
to
do
that
was
based
on
attached
I,
checked
to
see
if
I
was
had
initialize
flag
set
and
I
went
in,
and
basically
a
counter
for
the
fact
that
I
had
a
model
said,
and
that
was
only
done
once.
However,
what
that
means
is
the
the
widget
is
completely
uninitialized
until
the
first
time
it's
attached.
So
again
you
have
this
problem
of.
You
have
to
wait
for
some
state
asynchronously
to
happen,
and
until
you
can
actually
interact
with
that
widget
because
it
sends.
D
E
The
only
way,
the
only
way
to
have
synchronous
code
that
works
exactly
the
way
it
looks
like
it's
going
to
work
is
to
have
a
constructor
that
doesn't
take
a
model
and
then
set
a
model
attribute,
and
then
everything
can
happen.
Synchronously
you
don't
have
to
you.
Don't
have
to
ever
do
any
checking
for
initialization
or
do
the
weird
post
message
that
needs
to
happen
now
or
anything
like
that.
That's.
B
E
B
That
you
have
to
have
a
two-stage
initialization.
If
you're
going
to
do
act
on
setting
up
the
widget
based
on
the
model,
attributes
I
mean
you
could
have
the
constructor
take
the
model
and
then
a
separate
dot
in
it
widget,
or
something
like
that.
Yes,
but
your
name,
which
is
in
it,
which
it
should
take
the
model
you
shouldn't,
set
the
model
to
constructor.
That's
what
I'm
hearing
you
say.
E
I'm
not
exactly
sure
what
you
mean
to
say
it
again.
Please
well.
E
D
C
D
B
E
Looking
I
just
get
even
as
just
just
to
be
nice
we
could
even
put
in
the
on
after
attached.
We
could
say:
look
if
model
is
null.
You
know,
throw
an
error,
then
you're
trying
to
attach
a
widget
that
doesn't
that,
where
models
know
that
way,
they'll
never
accidentally
try
to
instantiate
a
widget
that
they
haven't
attached
to
the
model.
To
then.
B
C
B
C
B
Or
you
can
have
both
solutions
like
layouts
right
now
in
phosphor,
where
you
can
pass
it
into
the
constructor
or
you
can
set
it
separately
and
and
but
you
can
only
set
at
once
and
if
you
said
it
in
the
constructor,
you
can't
have
set
layout
at
least
I.
Think
that's
how
phosphor
used
to
work.
I,
don't
know
if
it
works.
Alright,.
B
Of
the
fundamental
action
of
that
thing,
like
the
box
panel,
you
set
the
box
layout
in
the
constructor,
because
that's
what
a
fox
panel
is.
D
Right
so
you're
you're,
hoping
that
the,
if
you
add
extra
logic
on
on
layout
change,
that
it's
not
relying
on
state
that
needed
to
be
set
in
the
in
its
own
constructor
on
that
sub
class.
It's
exactly
the
fire
that
we're
trying
to
prevent
right,
but
in
this
case
we're
pretty
sure
something
is
going
to
happen
in
the
subclass
when
you
set
a
model.
So
we
cannot
set
it
in
the
constructor.
B
B
Yeah
we
could
do
the
we
could
do
a
two-stage
construction
phase
and
initialization
phase,
and
that's
just
our
API
you
construct
and
that's
where
I
mean
we
could
pattered
it
after
the
pipe
there's
I
pond
where,
where
the
attributes
are
set
up
in
the
constructor
and
then
the
initialization
is
where
it
was,
what
everybody
should
override
the
backbone?
Has
this
to
actually
wear
the
constructor?
You
don't
authorize
you
just
override
the
initialize
method,.
E
B
E
E
C
Mean
I
I
think
I
probably
agree
with
that,
then
that
it's
known
like,
if
you
think
about
teaching
this
people
would
say.
Oh
well,
of
course,
you've
said
in
your
model,
whereas
if
we
have
an,
it
call
I
think
they
all
of
a
sudden
they
people.
Why
do
we
have
to
call
in
it
there's
already
a
constructor,
the
Constructors
taking
the
arguments?
That's
stupid,
just
calling
it
automatically
in
the
constructor,
and
then
we
add
definition
to
tell
me
how.
C
B
B
E
E
Options
are
things
like
renderers,
so
you
can
actually
for
base
salvage
it.
You
could
initialize
and
not
send
anything
in
it
default
to
everything
you
need
for
the
bore
the
mark
down
actually
yeah
for
all
of
them,
they'll
default
to
a
renderer,
so
you
can
initialize
without
passing
anything
in
and
they
do
have
other
attributes.
Those
attributes
are
not
consequential
in
the
way
model
is
it's.
E
But
but
yeah
the
only
really
consequential
one,
at
least
in
the
cells
mahou.
A
E
E
I
think
the
point
about
being
able,
in
the
future
that
you
enjoy
our
minds
and
decide
that
these
will
not
be
read-only,
I,
think
leaving
that
door
open,
is
good
and
having
having
that
pattern
of
just
setting.
The
attribute
means
that
if,
at
some
point,
anybody
actually
wants
it
first
off
we'll
have
a
good
we'll,
have
a
good
rationale.
We'll
have
a
good
story
behind.
Why
we're
now,
enabling
it
and
secondly,
it'll
be
backward
compatible.
No
will
be
surprised.
A.
B
D
E
C
C
Other
issue
is
that
some,
obviously
a
lot
of
widgets
don't
have
bottles
and
I'm
a
little.
If
we,
if
we
had
a
separate
initialization
method,
I'm
a
little
worried
about
the
fact
that
some
widgets
would
have
that
in
some
widgets.
What
won't
I
think
that
would
be
confusing,
whereas
some
it's
a
little
more
clear
to
me
that
some
widgets
have
models
in
some
widgets.
Don't
so
I
like
that,
the
API
around
this
focusing
on
the
bottles
rather
than
some
mysterious
init
method.
That
needs
to
be
called.
C
D
D
B
C
E
E
No
they're
not
gonna,
get
called
because
the
method
that
a
few
uses
the
model
it's
called
on-
model
change
and
it's
only
going
to
fire
if
the
model
has
been
changed
to
a
nominal
value,
so
you're
still
just
never
going
to
reference.
The
model
we
might
want
to
in
the
on.
After
attach
method,
we
might
want
to
add
courtesy,
have
a
thing
that
says
if
models
know
throw
an
error,
so
the
developer
knows,
but.
C
E
Right,
that's
why
I'm
suggesting
in
the
after
attach
method
you
could
just
yeah
throw
an
error.
You
can
do
a
console
warn.
You
can
do
any
number
of
things
that
nobody
should
push
code
once
they
see
so
like
yeah.
If
anyone
wants
to
see
their
thing
appear
on
the
screen,
they
will
see
it
throwing
error
if
we
put
it
in
there,
yeah.
B
E
D
E
I
was
thinking
about
this
yesterday
I
was
what
I
was
doing,
was
the
asynchronous
way
and
then
with
Steven
I
talked
this
morning.
It
just
became
clear
that
we
don't
want
to
have
anything
asynchronously
happening.
That
appears
to
be
synchronous,
because
that'll
just
confuse
anyone
want
to
reason
about
yeah.
B
B
D
B
C
E
C
E
So
those
are
not
actually
okay,
so
those
are
those
are
standalone
functions
or
things
that
could
have
been
potentially
static
method,
but
we
don't
want
them
to
be
publicly
available,
so
you
can't
have
one
way
we
could
have
done
it.
It's
so,
if
simply
made
them
be
functions
in
that
file,
because
then
they
would
have
been
private
to
that
file.
E
So,
for
example,
we
share
say
a
signal
instance
among
multiple
instances,
but
we
didn't
want
that
to
be
a
statically
accessible
variable
and
we
use
some
functions
that,
like
so
the
the
factories
right
now
that
create
your
various
nodes.
Those
are
things
that
don't
really
require
they're,
not
they're.
Not
we
don't
want
to
make
them
be
private
methods,
because
you
only
need
one
and
they
don't
rely
on
being
part
of
an
innocence
or
anything
so
just
as
a
housekeeping
measure.
E
Instead
of
having
the
file
littered
with
a
bunch
of
top-level
things,
we
have
a
smaller
number
of
top-level
things
and
the
things
that
truly
are
supposed
to
be
static
will
put
in
a
namespace
that
has
a
name
as
the
class
and
the
things
that
are
truly.
Our
private
will
put
the
namespace
called
private
that
way,
it's
just
that
the
file
itself
has
a
very
small
number
of
top-level
things
and.
B
When
you're
calling
it
it's
clear
that
this
is
a
not
exported
function,
I
mean
you
could
just
make
it
a
not
exported
function
at
the
top
level.
Balance
the
bottom
of
your
file,
but
having
a
private
namespace,
makes
it
clear
when
you
call
it
that
this
is
not
an
exported
function.
This
is
something
of
reserving
but
did.
Are
you?
Are
you
implying
darian
that
you're
moving
away
from
static
attributes
and
classes
not.
D
Only
the
ones
that
are
art
we're
using
static
and
that
namespace
will
be
called
the
name
of
the
class
sort
of
be
shared.
So
if
you
see
like
there's,
there's
class
static,
notebook
and
namespace
diagonal
book
for
static
things
associated
with
the
notebook,
but
things
that
aren't
supposed
to
be
publicly
seen
or
down
in
that
that
the
private
namespace
so.
E
B
D
Message
that
it's
it's
more
aesthetic
I
believe
them
and
the
end
result
is
the
same.
It's
still
static,
method
or
attribute
on
on
the
class.
It's
more
of
a
I.
Would
my
guess
would
be
more
of
a
bookkeeping
thing
where
you
you're,
focusing
on
the
instance
methods
and
then,
if
you
want
to
go,
look
at
the
static
it's
down
below,
but
yeah
Chris
Christian
I
have.
D
D
Method
of
despite
its
happening
yeah,
yes,
things
that
were
static
methods
in
on
even
on
existing
foster
classes,
are
moving
into
constructor
arguments
that
are
threaded
through,
so
that
you
don't
have
to
subclass
and
overwrite
of
a
static
method.
You
can
just
customized
by
passing
in
different
instructor
args,
and
then
we
are.
We
had
already
moved
some
things
that
were
like
interfaces
down
to
the
this
exported
namespace
that
so
it's
still
part
of
static
notebook.
D
B
D
B
B
D
No,
the
the
model
that
the
pattern
that
I
was
copying
from
Chris
was
to
make
it
not
private,
and
the
reason
for
that
is,
you
can
use
that
object
using
object,
decree
and
actually
just
override
one
of
the
properties
of
it
and
so
they're
supporting
that
use
case
right.
So
you
can.
You
can
sub
class
that
that
are
of
that
object,
use
it
as
a
prototype
using
the
object,
aakhri
and
just
override
one
of
the
three
methods
in
for
example.
So
that's
what
that
use.
B
Case
is
supporting
oh,
so
you're
factored
wait.
Okay,
so
your
factories
are
starting
to
become
complete
objects
in
themselves,
instead
of
just
function,
right,
I'd
and
then
yeah
once
it
becomes
an
object
of
itself,
you
need
it
to
be
separated
from
like
a
method
that
aesthetic
method
on
the
class.
Okay,.
D
D
I
did
I
did
start
doing
that
on
the
outputs,
PR
I
list
of
some
of
the
changes
there,
so
I
will
be
fed
up
with
what
we
discussed
today
and
some
of
the
rationale
there.
So
it's
captured
somewhere
great
okay.
C
It
may
make
sense
for
us
to
document
sort
of
architectural
choices.
We're
making
like
this
like
the
but
in
part
of
it
is
when
other
developers
come
and
start
working
on
the
code
base.
There's
they
will
have
to
make
the
same
choices
and
it
would
be
I
think
we
can
record
to
them.
Here's
sort
of
the
architectural
Cove
code
designs.
B
D
E
B
C
C
C
A
There
it's
frantic
to
start
our
meeting
for
an
80
to
1015
I.
Don't
just
share
with
you
guys
that
I
gave
a
talk
yesterday,
I'm
in
LA
right
now,
and
there
was
a
half
day
workshop
gone
by
data
science
inc
and
then
the
West
Big
Data
innovation
hub,
which
is
an
NSF
funded
initiative.
So
I
was
15
minute
talk
about
Jupiter
and
at
the
end,
I
had
one
slide
on
Jupiter
lab
and
brought
in
that
the
gift
from
the
super
lab
repo
that
just
kind
of
shows
the
windows,
the
tiles
getting
moved
around.