►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
B
C
D
I
don't
know
if
that
matters
that
that
would
break
making
it
extensible,
though,
because
then
you
would
need
somebody
to
pass
something
from
the
caller
that
wasn't
like
just
the
end
point
otherwise
you're
just
kind
of
forced
to
store
a
map
somewhere
else
from
end
point.
To
at
least
I
mean
you'd,
it
would
be
the
kind
of
thing.
C
E
B
The
the
funk
on
soccer's
http
handler
should
be
get
set.
Property.
B
E
B
As
far
as
I
know,
100
of
the
people
whose
names
are
on
the
cover
of
the
book
disagree
with
the
rule
that
classes
should
be
unsealed
by
default,
but
yeah
anders
believes
classes
should
be
unsealed
by
default
and
he
wrote
the
language.
So
he
won.
B
I
mean
there's
not
really
like
nothing
on
its
virtual,
so
you're
not
going
to
get
a
d
virtualization
benefit.
No
one
should
really
be
able
to
pass
this
in
somewhere,
but
maybe
someone
wants
to
extend
it
for
mocking
reasons,
and
I
don't
see
a
reason
to
hurt
them
like
going
back
to
what
the
rule
says.
It's
if
you
want
to
seal
something
you
should
have
a
reason,
and
I
don't
see
what
the
reason
would
be
here.
G
F
B
We
do
not
say
seal
it
by
default
unless.
B
Things
complicated
things
that
we
think
someone
inheriting
may
in
fact
break
things
we
we
seal
but
or
if
it
has
yeah
complicated,
other
complicated
consequences,
but
we
definitely
say
non-virtual
unless
you
need
it.
But
sealed
is
a
word
that
we
generally
don't
recommend
because
anders
doesn't
like
it
when
we
recommend
it.
F
At
that
point,
it
doesn't
make
sense
to
leave
it
unsealed,
because
no
one
could
ever
instantiate
this
thing
with
any
reasonable
effect.
E
A
E
A
A
B
E
B
If
we
have
a
sealed
type
that
is
non-constructable,
then
then
certainly
mocking
is
hurt.
At
that
point,
do
we
have
init
in
the
languages
that
we're
using
in
five.
F
B
F
B
But
if
it's,
if,
if
the
public
api
looked
like
this,
but
without
the
sets-
oh,
I
guess
you'd
have
to
declare
the
internal
constructor
or
it
would
be
default
constructable
still
but
like.
If
there's
no
way
you
can
provide
those
values,
then
you
wouldn't
ever
be
able
to
test
your
thing
without
reflection,
yeah
yeah,
which
clearly
we
don't
want
to
force
people
to
do.
F
E
That's
what
I
just
had
the
design
that
I
have
like
to
me
like
things
like
this,
that
are
just
effectively
just
parameters.
There
really
isn't
a
lot
of
value
in
ceiling,
because
to
me
the
value
and
ceiling
is,
as
jeremy
indicated
earlier
as
like,
when
you
have
a
polymorphic
class
hierarchy
with
virtuals.
E
B
H
H
E
A
C
B
E
B
B
Our
general
expectation
is,
if
someone's
going
to
have
to
ever
type
it
or
possibly
ever
type
it.
Then
it
should
not
be
nested,
but
things
like
using
a
custom
enumerator
from
you
know,
get
a
numerator.
It's
they
probably
just
slapped
it
in
a
for
each
and
the
type
name
never
even
showed
up
on
their
screen
yeah.
So.
E
H
I'm
fine
with
either
based
on
you
know
thing
that
we
use
the
factory
as
well
with
hdp
factory.
Only
I
mean.
A
B
E
All
right,
then,
I
do
what's
easiest
for
me
and
just
leave
it
with
the
one
that
already
sent
the
chant
or
in
the
thing
or
anything
else,
or
is
that
it
did
this.
Does
this
list
anything
did
we
say
anything
else,
so
they
should
edit.
The
bullet
points.
B
Yeah,
it
helps
testability,
nobody
has
any
real
re
like
if
you
get
one
and
you
set
it
to
null
inside
your
own
callback,
like
you
only
hurt
yourself,
so
I
don't
doesn't
the
only
penalty
that
you
would
get
from
having
the
setter
be
public?
Is
that
you
can't
reuse
the
objects
across
multiple
calls,
but
yep
can't
reuse.
The
objects
across
multiple
calls
so.
D
A
F
B
B
B
A
If
these,
if
those
properties
are
not
nullable,
it's
gonna
be
default,
and
knitted
to
null,
though
here
right
right,
like
is,
is
that
is
this
valid?
Are
we
doing
something
bad
there.
F
I
think
pocos
tend
not
to
use,
tend
not
to
use
notable
annotations.
Do
they.
We
use
them
everywhere
in
the
bcl.
Now
we
don't
have
pocos
on
the
bcl.
Do
we
for
the
most
part.
E
Yeah,
I
guess
in
our
case
most
of
the
stuff.
This
happens
to
be
read
only
right,
yeah,
I
don't
know
that's
a
good
question
actually,
because
I
mean
making
another
book
will
kind
of
suck,
because
not
everybody
who
just
handles
the
stuff
now
gets
warnings
unless
they
do
something
about
it
and
realistically
they
should
never
ever
receive
a
null.
E
F
F
B
E
I
think
at
this
point,
I'm
honestly
at
the
point
where
just
make
them
get
only
and
then
not
have
a
public
constructor,
because
I
mean
it's
yeah.
It
seems
weird
to
me
that
we
can
now,
if
we
add
another
property
like
we
can't
technically
make
it
nullable
now
and
non-valuable
anymore,
because
if
somebody
called
the
other
constructor,
it
would
be
now
like.
What's
the
point,
then.
E
A
I
I
don't
know
if
this
should
affect
the
decision,
but
here
but
http
client
is
already
annoying
for
people
to
mock,
maybe
making
it
more
annoying.
It
isn't
isn't
great.
But
since
this
is
a
super
advanced
api,
it
will
probably
be
fine.
B
E
A
B
E
B
The
private,
so
it
the
private,
socket,
http
connection
contacts,
prem
print
wow.
F
To
your
question
it
it
has
too
many
weird
implications
for
extensibility.
If
we
were
to.
E
Yeah,
that's
that's
the
down
type
of
null
annotations
right,
because
if
the
problem
is,
if
you
have
a
public
get
set
or
effectively
a
constructor
version,
it
doesn't
really
matter.
The
question
is
now:
if
somebody
calls
the
older
constructor
that
didn't
set
it,
then
it
must
be
nullable
right,
and
so
that
is
not
great
for
consumers
and
since
most
of
the
people
will
just
consume
it,
we
don't
want
them
to
have
to
check
for
null
for
things
that
will
never
be
null.
That
seems
backwards.
E
C
Doesn't
that
break
people
like
if
I've
written
code
that
you
know
there's
two
properties
today
I
write
code
that
emits
those
two
properties.
Now
in
the
next
release,
we
got
a
third
property
that
is
get
in
it
and
I'm
is
as
like
is
that
gonna
fail
to
compile,
because
now
there's
a
new
property
I'm
supposed
to
win
it.
E
I
mean
that
seems
almost
like.
We
need
to.
We
need
a
new
concept.
It's
like
you
know.
You
should
initialize
this
basically
right,
because
I
don't
know
to
me
making
marking
all
these
new
things
nullable.
That
seems
maybe
okay
in
version
one.
But
if
you
look
if
you're
in
version
four
and
you
look
back
and
now
75
of
the
new
editions
are
all
available
just
because
you
did
them
after
we
won
that
would
suck
right
so
like.
I
think
we
would
have
to
think
about
how
we
want
to
model
this.
E
I
could
imagine
like
we
just
basically
go
with
get
in
it
and
then
we
add
a
new
custom
attribute
that
says.
Well,
if
you
initialize
this
type,
you
should
initialize
this
thing
as
well,
and
then
people
would
just
get
warnings
for
the
for
the
v1
code,
where
they
don't
initialize
things
and
says.
Well
you
you
should
initialize
this
thing
you
haven't.
So
it's
not,
but.
B
B
It's
more
of
when
it's
a
if
it's
an
output
object,
which
this
sort
of
is
it's
an
output
of
the
http
handler
class
into
the
callback,
like
the
only
people
who
really
build
this
in
real
code.
Is
us
and
we
promise
they're
never
null?
But
if
you
build
them
in
your
test,
then
they
might
be
null.
And
if
you.
B
E
F
Yeah
yeah,
I
marked
it
just
because
when,
when
we
obsoleted
thread
dot
abort,
we
also
forgot
to
obsolete
reset
abort.
My
suggestion
is:
we
just
use
the
same
obsoletion
code
that
we
did
with
the
port
reset.
E
E
F
We
we
talked
about
various
overloads
of
abort,
but
I
don't
remember
reset
abort
ever
coming
up.
If
it
did
come
up,
it
was
just
an
oversight
that
we
forgot
to
market.
I
don't
think.
E
F
J
F
Yeah
and
that
is
kind
of
what
we
were
doing
with
a
lot
of
the
observations
that
were
introduced
in
3-1
or
I'm
sorry.
In
5-0
we
were,
we
were
trying
to
be
a
little
judicious
in
what
we
obsolated
in
5-0,
but
we
are
kind
of
on
a
tear
to
annotate.
Every
single
one
of
those
apis
would
stop
calling
me
in
5.0
we
obsoleted
thread.abort,
so
it
would
make
sense
that
this
should
have
been
in
that
same
slot.
We
just
forgot
about
it.
J
J
E
I
can
improve
the
tooling
like
the
problem
is.
I
can
only
look
at
one
implementation
at
a
time
right,
so
I
can't
tell
easily
whether
all
implementations
throw
so
I
just
index
all
builds
and
then,
if
they
all
say
they
throw,
then
it's
easier.
I
think
the
other
thing
is.
The
tool
is
very
liberal
right,
because
our
throat
patterns
in
the
bcl
are
bad
crazy.
E
So
I
don't
just
check
whether
the
body
is
just
to
a
new
platform,
not
supported
exception,
it's
more
like
well,
you
call
some
helper
method
and
that
one
returns
an
exception
and
then
the
calls
are
just
the
throw
and
all
of
that,
and
so
that
can
sometimes
return
in
false
positives.
So
maybe
I
need
some
sort
of
like
no.
I
know
for
a
fact.
This
always
throws
because
there's
no
other
code
around
it,
but
that's
usually
not
how
we
encode
it.
E
So
it
seems
like
regardless
of
this
one.
I
think
we're
all
in
agreement
that
even
so
this
is
post
five
all
right,
so
this
is
for
6.0.
So
we
are
okay
with.
B
Off
I
was
going
to
ask
that
question,
because
this
is
back
to
the
good
old
warnings
as
error.
That
means
that
you
upgrade
from
five
to
six
now
an
error
that
you've
already
dealt
with
is
manifesting
elsewhere
and,
if
we're
okay
with
that,
that's
fine.
I
just
know
that,
especially
since
jared's
on
the
call
now,
that's
historically
been
why
obsolete
was
hard.
J
J
Time,
though,
it
was
also
the
reason
why
it
was
hard
is
because
upgrading
your
tool
set
was
indistinguishable
from
like
upgrading
what
you
were
targeting
so
basically
because
visual
studio,
you
install
a
new
visual
studio.
You
implicitly
move
to
c-sharp
latest,
but
now
because
of
how
tfm
and
reference
assemblies
work
like.
If
I,
if
I
install
net
6x
sdk,
with
the
exception
of
your,
if
defs
it
doesn't
change
what
your
it
doesn't
change
the
reference
assemblies
you're
using
it
doesn't
change
the
warning
level.
J
It
doesn't
change
the
language
version,
so
installing
the
sdk
is
no
longer
the
thing
that
gives
you
new
information.
It's
when
you
change
your
tfm,
that's
when
the
information
and
warnings
change
which
we
have
at
least
been
on
the
belief
that,
because
that's
an
explicit
user
action,
it's
okay
to
attach
some
cost
to
it.
E
Yeah
and
yeah,
so
my
the
reason
why
I
think
using
an
existing
diagnostic
makes
sense
is
that
if
you
already
handle
that
exception,
sorry,
if
you
already
handled
that
diagnostic
id
before
you
decided
you
don't
care,
it's
actually
beneficial
to
reuse
the
existing
one,
because
you're
just
saying
yeah,
if
you
already
decided
you
don't
care,
then
you
still
don't
care
because
it's
the
same
sort
of
obsoletion
right.
So
I
think
that
that
makes
sense.
I
I.
E
Well,
if
you
know
wonder
if
you
just
you
know,
did
the
editor
config
setting
for
syslip006
right,
there's
multiple
ways
you
can
suppress
it
globally.
E
Right
so,
but
that's
what
I'm
saying
like
if
you,
if
you
have
you,
if
you
decided
you
don't
care,
then
it
still
makes
sense
to
use
existing
one.
If
you
decided
you
do
care
and
you
wrote
custom
code
to
handle
that.
Well,
then
we
tell
you
that
oh
you're
missing
this
case
over
here,
but
and
so
in
that
sense,
I
think
it's
actually
useful
to
reuse
the
existing
one,
because
you
you
tell
the
customer.
Okay,
here's
a
new
thing.
If
you
forgot
about.
F
No,
it's
it's
a
good
question.
I've
I've
at
least
our
process
in
our
processes.
Internally,
traditionally,
we've
had
a
list
of
obsoletions
that
were
safe
or
sorry,
a
list
of
warnings
that
were
generally
safe
to
ignore
and
a
list
of
warnings
that
you
had
to
go
through
other
people
and
kind
of
get
their
sign
off
before
you
suppress
them.
F
If
we're,
if
you
as
a
developer,
have
already
said
this
particular
warning
is
safe
to
ignore,
as
opposed
to
something
that
has
real
world
impact
on
an
application,
then
reusing
that
would
allow
you
to
use
whatever
existing
sign-off
processes
you
have,
rather
than
have
to
like
go
set
up
a
new.
Well,
let's
analyze
this
particular
warning
code
for
anything
that
might
be
of
consequence
to
us
blah
blah
blah
so
yeah
it
does.
It
does
potentially
force
people
to
react,
but
the
reaction
should
be
a
little
easier
if
we're
using
an
existing
code.
F
F
F
E
F
I
have
all
of
them
registered.
They
just
don't
really
link
anywhere
right
now,
because
we
didn't
have
the
docs
up
yet.
E
F
E
I
guess
this
is
the
view
it's
probably
the
best
one,
so
I
just
ignore
the
typos
blah
blah
blah
blah.
E
Yeah,
I
guess
let
me
do
this.
Let
me
open
this
in
a
secondary
tab,
walk
you
through
the
thing
and
then
we
can
go
over
the
comments.
Otherwise
it's
a
bit
weird
to
jump
to
the
comments
without
any
any
context.
So
we
talked
about
this
last
week
with
kristoff.
I
don't
think
christopher's
on
the
call
today,
probably
too
short.
E
At
11.
all
right,
so
then
here's
three
minutes
and
I
can
just
give
the
rest
of
the
people
who
are
not
here
yet
some
context,
no,
the
rest
of
the
people
who
haven't
been
there
last
time.
I
can
give
them
some
context
this
way,
so
krista
was
asking
for
a
type
called
binary
data.
So
the
context
goes
like
this,
so
we
have
a
lot
of
types
in
the
bcl
that
deal
with
binary
data.
You
know,
of
course
we
have
byte
arrays.
E
You
also
have
streams
and
we
have
spans
and
memories
and
all
that,
and
so
the
problem
with
these
kind
of
types
is
that
first
of
all,
there's
multiple
but
then
also
that
is
kind
of
you
know,
complicated
by
the
fact
that
effectively,
it's
not
just
about
the
actual
data
holder.
It's
also
about
the
thing
that
you're
converting
from
and
to,
and
that's
really
where
the
hits
the
fan
so
to
speak,
because
we
have
you
know,
string
streams,
potentially
object
wraps.
E
E
How
do
I
get
my
object
graph
into
a
stream
form
and
so
the
the
the
way
that
they
solve
the
problem
is
we're
basically
just
saying:
let's
have
a
single
type
called
binary
data,
and
so
the
underlying
api,
instead
of
taking
span
of
byte,
let's
say,
actually
takes
binary
data
and
then
when
people
see
that
in
intellisense
they
can
just
new
up
binary
data,
they
immediately
discover
their
constructor.
So
there's
you
know
properties
they
can
use
to.
E
Actually
initialize
this
thing
to
something
sensible
and
then
they
immediately
know
how
to
use
the
api.
E
So,
basically,
what
I
have
here
is:
I
have
like
written
up
some
scenarios
to
kind
of
explain
what
this
looks
like.
So
imagine
you
use
azure
storage
cues,
so
you
have
a
queue,
client
and
then
what
you
want
to
do
is
you
want
to
cue
an
item
that
basically
says.
I
want
to
resize
my
image
and
so
the
way
you
do
this
is
storage
cubes.
E
Basically,
you
have,
I
think,
4k
whatever
for
a
message,
so
you
don't
usually
post
the
actual
data
you
want
to
do
you,
you,
post
something
that
refers
to
the
data
that
you
want
to
process,
and
so
you
have
your
own
custom
format.
In
my
case
I
made
up
this.
You
know
resize
image
class
and
basically
that
describes.
I
want
this
image
in
this
url
resize
to
these
resolutions
right
and
then
you
just
serialize
this
thing
into,
let's
say:
json
payload
and
that's
what
you
actually
store
in
the
queue
and
so
with
binary
data.
E
Okay,
I
don't
know
what
that
is,
and
then
the
usual
pattern
is
they
just
try
to
new
the
type
up
which
they
can,
because
they
have
a
public
constructor
and
then
they
have
just
instance,
methods
on
them
that
allows
them
to,
for
example,
set
the
data
from
from
object
graph
that
is
now
being
serialized
as
json,
and
then
retrieving
site
is
very
similar
like
basically,
when
you
say
you
know,
looks
a
bit
different
with
storage
queues.
E
Usually
you
have
a
you
know,
callback
pattern
where
you
know
every
time
somebody
posted
the
queue
they
actually
call
you
with
azure
functions
and
then
just
pass
you
the
payload
from
the
queue
in
this
case.
It
would
just
give
you
the
payload
as
binary
data
and
then
again
you
consume
by
you
can
say
you
know
binary
data
dot,
and
then
you
find
it
out.
E
You
know,
in
this
case
the
the
instance
method
here
to
object
from
json
and
then
the
usual
pattern
that
we
have
is
that
you
use
a
generic
argument
to
actually
specify
what
you
want
to
decide
as
an
under.
Then
you
get
your
stuff
out
right.
So
that's
roughly
the
idea
of
the
type
does
that
make
sense
to
people.
E
E
E
It
should
be
possible
for
people
to
do
that,
but
we
also
okay
with
saying
you
know.
If,
if
you
do
something
super
custom,
that's
fine,
the
type
can
already
be
constructed
from
the
from
a
span
or
from
a
byte
array.
You
do
whatever
you
want
to
do,
and
you
just
give
us
the
byte
array
right.
So
we
don't
feel
like
we
need
to
support
every
single
whistle
because
there's
always
this
ultimate
escape
hatch
anyway,
but
basically
one
of
the
things
you
want
to
do
is
you
want
to
say
well.
E
This
thing
is
used
in
you
know
in
in
the
context
of
of
a
cloud
platform,
and
so
you
know
strings
are
usually
utf-8
and
then
for
object.
Realization,
we
just
pick
whatever
defaults.
We
think
makes
sense
for
the
options,
because
the
goal
really
is
to
just
get
people
going.
It's
not
to
allow
arbitrary
encodings.
E
We
don't
have
a
goal
to
make
this
api
super
high
performance.
I
mean,
of
course
we
don't
want
to
make
it
dark
slow,
but
like
it's
not
one
of
those
patterns
where
we
really
shoot
for
zero
allocations
right.
So
if
there's
copying
going
on
that's
fine,
the
goal
here
is
usability,
not
perth.
E
So
as
far
as
design
goes,
let
me
just
scroll
down
so
the
biggest
I
think
room
of
contention
is
last
time
we
already
talked
about
this.
Is
that
the
basically
the
design
that
kristoff
gave
us
jesus
orange
juice
is
really
sticky,
so
basically
the
binder
data
that
he
designed
basically
has
the
the
json
civilization
built
into
it,
which
basically
allows
us
to
have
regular
constructors
and
regular
instance
methods.
And
so
what
I
was
toying
around
with
was
the
idea
that
we
described
last
time,
which
is
basically
well
what?
E
If
we
don't
do
that,
what
if
we
basically
only
have
regular
instance
methods,
because
that
allows
us
to
use
normal
extension
methods
and
then
we
just
have
a
public
constructor
that
you
can't
see
here,
because
it's
a
struct
and
then
we
basically
just
say:
look
we
allow
it
to
construct
the
object
or
in
this
case
destruct
and
then
you
just
call
you
know,
set
bytes
or
set.
What
is
it
set
object
as
json
async
and
then
everything
else
just
falls
out,
and
so
there's
a
I'm
pretty
sure.
E
E
So
I
I'm
pretty
sure
you
have
opinions
on
on
this
extension
method
stuff
here,
but
like
like
all
the
things
I
said
before,
the
requirements,
the
general
thing
about
how
we
anticipate
the
type
to
be
users.
All
of
that
is
a
fair
representation
of
what
you
told
me.
K
K
K
It's
basically
a
trade-off
between
the
ability
to
move
the
type
down
in
the
dependency
hierarchy
and
usability
this
type
being
immutable
and
not
having
weird
empty
constructor
that
then
you
know
you
have
to
call
some
methods
to
initialize
the
type.
So
I
I
think,
unless
we
think
we
want
to
move
it
to
the
core
of
the
bcl,
I
would
optimize,
for
you
know,
usability
and
the
type
being
immutable.
B
B
Edge
cases
and
that
the
extension
method,
pure
extension
methods,
while
it
does
look
a
little
weird
that
to
me
it
feels
like
it.
It
gives
us
a
better
path
forward
on
things,
and
it
means
that
we
don't
end
up
with
this
heavily
coupled
type,
because
it's
only
as
coupled
it's
only
coupled
to
the
things
that
you
use
the
extension
methods
from.
K
I
worry
that
if
we
start
playing
with
some
strange
tab
that
doesn't
have
a
constructor,
but
it
has
a
default
one
that
doesn't
mean
anything,
makes
it
into
an
empty
type,
and
then
you
know
methods
to
to
mutate
the
the
instance
we
are
kind
of
you
know
doing
an
experiment,
and
I
I
questioned
the
goals
of
this
experiment,
like
this
kind
of
you
know,
refactoring
really
like
designing
for
the
future
that
we,
I
don't
know
you
know
if
we,
if
it
ever
will
come
it's
just
it's
it's
very
risky.
K
E
So
I
agree
with
the
israeli
testing
so
like
to
me.
That
seems
that
I
think
I've
said
it
somewhere
in
the
in
the
actually
it's
at
the
very
top
of
the
screen
right
now
so
like
yeah,
I
think
we
need
to
test
that
and
if
it
turns
out
to
be
a
major
bump,
we
shouldn't
do
it.
I
think
the
question
now
becomes.
How
do
we
have
enough
time
to
test
that?
E
To
jeremy's
point,
though,
what
I
find
appealing
you
know,
modulo,
the
the
layering
issue
is
also
that
we
can
handle
a
single
non-async
in
the
same
fashion.
It
kind
of
irks
me
that
we
can't
do
async
with
constructors,
because
it
kind
of
creates
this
wheeled
this
very
weird
dichotomy
where
well,
if
you
want
to
have
it
easy,
then
you
don't
use
async
and
it
seems
like
you,
just
ask
people
to
move
mechanics
for
not
a
lot
of
good
reasons.
E
In
my
opinion,
yes,
I
think
there
is
some
weirdness
with
the
syntax,
but
I
think
after
having
written
some
sample
code,
I
kind
of
convinced
myself
that
I
actually
don't
mind
it
too
much.
I
actually
think
it
looks
fairly
reasonable
with
the
extension
syntax.
E
So
people
can't
accidentally
mutate
state
when
they
didn't
intend
to,
but
yeah
I'm
curious
what
people
do
pretty
much
after
the
the
newing
up
thing
right,
but
they
actually
figure
out
that
they
should
call
some
instance
method,
whether
they're
completely
lost.
E
K
Resources
for
the
usability
studies
like
I
I
I
don't
know
how
I
could
justify
spending
the
resources
on
testing,
something
that
is
a
very
strange
design
that
we
don't
have
anywhere
else
in
the
bcl
like
do.
We
have
mutable
structs
because
we
didn't
want
to
have
a
constructor,
so
we
added
extension
methods
and
structs
that
mutate
them
like
it's
like.
It
violates
so
many
of
our
guidelines
that
I
don't
know
how.
I
would
justify
the
usability
study.
E
Well,
as
I
said,
like
the
type
wouldn't
be
mutable
right,
it
would
effectively
be
in
it
only,
but
the
question
is
yeah.
I
mean
to
me
the
the
cost
justification.
Is
we
try
to
make
a
type
that
is
currently
basically
local
to
the
area
to
the
azure
sdk,
when
I
make
this
a
platform
type,
and
there
are
some
costs
in
doing
that,
and
that
will
be
part
of
the
ability
to
study.
B
B
Well,
if
they
didn't
call
in,
he
said
it
would
have
a
default
state
and
that
would
need
to
be
dealt
with
no
matter
what,
because
it's
destruct
and
then,
if
they
call
any
of
the
set
methods
they
just
can't
call
a
second
one
so
that
the
thing
that
would
stop
is
the
expectation
that,
if
you've
received
one
that
you
can
call
set.
Yes,
there's
a
set
method.
It'll
just
literally
never
work,
and
if
it
did
work,
then
your
context
wasn't
going
to
work.
K
E
Yeah,
I'm
not
sure
I
follow
entirely
because,
yes,
the
type
has
effectively
free
semantics,
but
I
mean
today
the
model
is
you,
you
get
the
type
and
you
you
can't
do
anything
with
it
right.
If
you
receive
a
binary
data,
you're
not
supposed
to
call
it
any
methods
on
it
anyway,
so
you
know,
except
for
extracting
information
from
it
so
like
that
hasn't
changed
right.
So
the
only
party
that
should
ever
use
set
is
the
party
that
constructs
binary
data,
which
is
localized
to
the
code.
That
does
that.
K
K
B
I
agree
extension
statics
are
better
because
then
it's
the
the
extension
static
built
it
and
the
instance
never
looked
mutable,
but
we
don't
have
that,
and
I
think
that
this
is
the
best
compromise
we
can
get.
I.
K
Yeah,
I
I
think
we
are
now
designing
a
different
type,
like
the
type
that
I
think
jeremy
you're
talking
about.
We
already
have,
it
is
read
only
memory,
just
add
bunch
of
extension
methods
on
top
of
it,
and
you
have
this
time
like
this
type,
is
meant
to
be
optimized
for
usability,
and
we
know
that
users
want
to
just
create
types
using
constructors.
K
Look
at
the
parameters
choose
whatever
they
want
to
use
to
initialize
it
and
then
have
a
simple
type.
That
has
you
know
it's
immutable
has
just
conversions
and
it
it
all
works.
I
I
think
we
adding
so
much
complexity
by
playing
these
tricks,
with
extension
methods
for
everything
that
I
I
I
think
it
it
changes.
What
the
type
is
and
makes
it
super
ugly.
E
K
E
If
we
really
wanted
to,
we
could
add
it
to
system
text
or
json
itself,
which
seems
very
weird
in
my
opinion,
but
that
would
be
an
option
we
could
pursue,
but
then
won't
you
look.
The
the
layering
concerns
that
this
thing
is
now
very
high
level.
You
also
have
this
problem.
E
If
we
ever
have
to
support
another
technology,
let's
say
protobuf
or
something,
then
the
design
gets
extremely
complicated
because
now
effectively,
what
we
have
to
do
is
this
thing:
if
it
lives
in
system
text.json,
then
systemtext.json
would
have
to
depend
on
protobuf,
which
I
don't
think
we
would
ever
do.
If
we
make
it
an
independent
assembly
that
depends
on
system
text.json,
then
yes,
this
assembly
could
depend
on
on
protobuf
and
systemtext.js
and
that
will
probably
be
acceptable.
E
K
Yeah,
I
just
I
just
think
it
crosses
my
threshold
of
being
ugly,
I
mean
honestly,
we
are
making
we
we
would
make
something
that
today
has
constructors
is
immurable
and
it's
very
simple
into
like
a
very
ugly
thing
with
weird
semantics.
I
so
if,
if
that's
the
case,
you
feel
like
you
cannot
live
with
this
design.
K
Maybe
we
just
ship
it
in
azure
core.
B
Yeah,
I
just
feel
that
it
doesn't
the
the
way,
with
the
statics
and
being
tightly
coupled
to
jason,
that
it
can't
grow
as
the
bcl
needs
it
to
grow,
but
the
if
we
had
it
and
again,
if
we
had
extension
statics,
it
would
totally
be
static
factories
and
we
would
just
glue
them
all
together
with
extension
patterns,
but
we
don't,
and
so
the
after
you
left
last
time
when
we
were
talking
about
how
many
different
serializers
are
trying
to
be
the
the
next
big
thing,
because
of
things
in
standardization
committees
right
now
and
and
whatnot
that
that
it's
gonna
get
coupled
to
something
else
soon
and
that's
going
to
make
it
get
very
ugly
or
very
fast.
B
E
E
K
E
Yeah
so
like
to
me,
so
I
think
an
acceptable
design
would
be.
We
have
a
standalone
nuclear
package
called
system
of
binary
data
which
it
turned
depends
on
system
text.json
and
then,
presumably,
if
another
stabilization
format
comes
online,
let's
say
protobuf
I'd
be
shocked
if
the
azure
sdk
wouldn't
have
to
depend
on
that
as
well
anyways,
in
which
case,
if
we
add
the
dependency
directly
to
system
binary
data
as
well,
and
now
you
have,
you
know,
different
static
methods
and
different
different
instance
methods
on
the
type
that
seems
fine.
K
Another
thing
I
would
you
know,
I
think
I
know
that
it
was,
you
know,
tried
and
it
was
deemed
difficult
to
do
this.
You
know
extensions
everything
feature.
E
E
So
the
problem
on
this
under
on
the
c-sharp
team
is,
I
think,
jared
dropped
off
was
that
part
of
the
design
initially
had
overlap
with
other
things
that
they
wanted
to
do,
and
so
I
think
they
still
don't
know
what
these
other
things
will
look
like.
So
it's
not
off
the
table,
but
it's
also
a
very
far
cry
from
having
a
design.
E
E
The
general
pushback
we
likely
get
is
that
it's
not
clear
what
the
syntax
would
be
and
usually
they
don't
like
asymmetry
in
those
cases,
but
I
think
that's
an
example
where,
in
my
opinion,
a
custom
attribute
would
be
totally
fine,
because
I
I
really
don't
care
what
you
have
to
do
on
the
authoring
side.
I
just
care
about
the
consumption
experience
but
again
like
even
if
we
were
to
do
that
likely
this
would
be.
E
K
Yeah,
but
I
was
thinking
like
you
know
what
we
would
do
if
we
shipped
it
as
a
high-level
component
and
then
we
wanted
to
add
a
new
serialization
format.
K
I
do
think
that
it
would
be
better
if
you
know
we
allowed
ending
new
serialization
formats,
but
for
that
you
know
for
that
we
have
some
more
time.
So
if
statics
extension
statics
were
added
to
c-sharp
right,
I
think
we
could
use
it
for
future
formats
that
show
up
in
you
know
three
five
years.
E
E
It's
ambiguous
that
you,
you
want
to
see
or
less
something
here,
but
with
what's
your
leather,
do
you
want
to
see,
allows
it
right,
so
the
we
would
only
have
the
constructors
that
are
actually
directly
coming
from
binomial
binolator
as
well,
and
then
everything
else
you
would
have
to
go
through
a
static
method
which
seems
fine
to
me.
It
also
removes
the
problem
with
async
right,
because
all
the
other
ones
are,
of
course,
not
async.
E
To
begin
with,
I'm
not
sure
how
you
feel
about
that,
but
I
mean
to
me
string
and
jason
are
not
things
that
have
to
go
through
a
constructor.
I
think
a
factory
would
be
fine.
K
For
other
serialization
formats,
yes,
I,
as
I
said
you
know
when
we
discussed
it
last
week,
once
people
learn
about
the
type
like
future,
evolution
doesn't
have
to
be
as
clean.
In
my
opinion,
because
once
you
understand
what
this
type
is
and
then
you
know
in
the
future,
there's
a
new
serialization
format.
You
probably
you
know
we
we
will
have
to
announce
or
we
will
have
to
say
hey.
You
know,
here's
a
package
and
it
supports
now.
You
know
protobuf,
let's
say.
E
Yeah
you
say
that
but
like
I
mean
just
look
at
him
like
how
the
type
would
look
like,
then
in
v3
right.
So
do
you
think
it's
obvious
when
people
say
new
binary
data
and
then
they
say
you
know
they're
passing
the
object
and
then
it
still
has
a
json
and
then
somewhere
down
the
code.
They're
basically
saying
no
instance
dot
from
object,
async
and
then
they
sorry
not
that
one
two
object
of
t
and
there's
no
confusion
that
this
goes
going
through.
Json.
K
K
Kind
of
know
that
you
looking
for
it
if,
if
you
don't
want
to
grab,
if
you
want
to
implement
the
feature
that
such
that
the
user
doesn't
need
to
know
about
an
extension
package.
Well,
then
you
need
to
take
direct
dependency
and
then
you
can
make
it
into
a
constructor
parameter
in
just
the
enum,
as
we
discussed
last
time,
which
is
basically
it's
an
enum
that
selects
which
serializer
you're
using
so
I
think
there
are
two
two
kind
of
paths.
K
One
is
relies
on
an
external
package
with
extension
methods,
and
at
that
point
I
know
what
I'm
looking
for.
I'm
trying
to
do.
Protobuf
extensions
on
on
binary
data,
and
if
we
are
okay
with
taking
direct
dependency
from
this
package
to
protobuf,
then
we
can
just
add
a
constructor
for
protobuf
civilization.
E
Yeah
I
mean
I
would
even
ignoring
you
know,
extensions
or
not,
even
if
you
assume
binary
directly
depends
on
it.
I
think
it's
always
weird
if
you
basically
call
a
constructor
where
the
encoding
or
data
type
isn't
clear
right
so,
for
example,
take
the
string
one
right,
we
said
the
string.
One
is
fine
because
we
don't
believe,
there's
any
scenario
where
somebody
wants
utf-16.
E
But
let's
say
we,
you
have
apis
where
both
utf-16
and
utf-8
would
be
sensible.
Then
we
generally
wouldn't
give
you
the
string
constructor
either
right.
We
would
generally
say
like
we,
oh
you
have
a
factory
method
and
the
naming
implies
whether
you
get
utf-8
or
utf-16
right.
So
we
try
to
avoid
ambiguity
and
shape.
E
Yeah
I
mean
I
mean
my
personal
argument
would
be
that,
because
it's
versioned
over
time,
people
don't
see
it
right.
They
only
see
the
resulting
call
side
and
then
they
have
to
with
their
intellisense
to
actually
see
oh
yeah
there's
an
overload.
It
takes
a
format.
Oh,
the
format
could
be
protobuf
or
jason,
and
I
passed
in
the
wrong
one
right
like
it.
How
discoverable
are
these
things
versus?
E
K
B
E
That's
kind
of
where
I'm
getting
it
like
like,
if
you,
if
you
basically
assert
in
v1,
we
will
not
we'll,
never
need
something
else,
and
so
we
ship
without
that
enum,
then
that
problem
exists
right.
If
we,
if
we
are
saying
in
v1,
we
already
assert
that
there
will
be
multiple
formats
and
it
might
just
be
two,
but
we
ship
this
thing
from
you
know
from
day.
One
with
you
have
to
specify
the
encoding
as
part
of
a
parameter.
Then
I
think
it's
also
fine.
K
So
you're
saying
that
if
we
added
an
overload
to
the
constructor,
let's,
let's
talk
about
the
string,
one,
if
we
add
it
in
a
future,
an
overload
that
takes
an
enum
with
two
values,
ctf8
and
utf-16.
That
would
not
be
discoverable.
Is
that
what
you're
saying?
Oh.
E
I
wouldn't
say
not,
I
would
say
less
I
mean
for
the
string
one.
I
think
we
convinced
ourselves
that
nobody
ever
cares
about
utf-16
or
utf-7
or
ascii.
So
utf-8
is
the
only
one
that
99
of
people
will
care
about
with
the
json
one.
I'm
not
convinced
that
the
percentage
will
be
99.
I
think
that,
as
jeremy
indicated,
I
think
very
quickly
there
will
be
maybe
70
30
60
40,
depending
on
your
viewpoint
right
whether
you
want
to
use
this
new
binary
thingy
or
you
want
to
use
json
right.
E
I
think
json
will
be
still
very
popular.
When
you
talk
about
the
rest
api,
you
want
to
consume
from
javascript,
but
if
you
just
use
it
as
a,
I
just
want
to
conveniently
get
this
object
model
in
some
sort
of
fashion,
so
it
can
persist
it.
I
think
people
will
care
about
other
things
way
more
than
about
the
fact
that
it's
json
right
and
then
basically
prioritizing
json.
The
api
might
be
a
mistake.
K
So
but
you
know
so
the
way
I
would
let's,
let's
explore,
you
know
what
could
happen
so,
let's
say
three
other
serialization
formats
are
become
popular
and
we
need
to
support
them
and
we
have
now
those
two
paths
correct
one
is:
we
have
extension.
Meth
is
static.
Extension
methods
for
c
sharp
in
c
sharp
right.
E
K
We
don't
right
so
if
we
had
static
extension
methods,
we
would
just
add
the
the
methods
from
n2
right
is
that
right?
If
we
don't,
we
would
add,
like
some
enum
value
and
take
direct
dependency
on
the
serialization
technologies.
K
E
Yeah
to
me
it's
like,
if
you
would
say
you
know,
we
don't
have
the
constructor
for
jason.
We
only
have
the
factory
methods
today.
I
think
that's
also
less
of
a
problem,
because
it's
named
right.
You
basically
indicate
what
you
are
getting
like
to
me.
E
The
problem
really,
is
you
pass
an
an
object
and
then,
if
you
look
at
the
call
side,
nothing
of
the
call
side
implies
json,
you
don't
pass
any
inum,
you
don't
have
a
named
method
and
then
later
on,
it
turns
out
there's
more
ways
to
do
that
and
it's
not
implementation
detail.
It's
totally
part
of
from
what
you
want
from
for
you
know
for
this
to
happen.
That
to
me
seems
like
a
trap.
If
in
v1
we
basically
say
this,
you
know
you
already
have
an
enum.
E
Edom
only
has
one
member
but
you're
always
forced
to
pass
it
in
then.
Basically,
all
the
call
sides
will
say
json
one
way
or
the
other.
They
either
say
it
as
part
of
the
enum
or
they
say
it
as
part
of
the
method
name.
But
then
it's
very
clear
that
you
know
you
get
jason
because
that's
what
you
asked
for,
and
so,
if
there's
multiple
options
now
well,
then
what
do
you
have
to
change?
Well,
if
it's
a
method
name,
you
call
the
different
method.
K
Yeah,
so
I
I
can
see
how
it's
not
ideal,
but
I
still
come
back
to.
I
think
evolution
like
this
after
a
couple
of
years
when
people
actually
understand
the
type,
is
you
know
it's
it?
In
my
opinion,
it
would
be
fine
if
it's
if
json
is
always
kind
of
maybe
a
bit
preferred
as
long
as
the
other
things
can
be
added
in
a
you
know,
reasonable
fashion
and
then.
K
Well,
no,
because
that
basically
changes
what
I
was
saying
like
when
you
ship
a
type
for
the
first
time.
In
my
opinion,
it
should
be
simple
and
do
exactly
what
users
want
then,
as
it
evolves
it's
fine
to
kind
of
slowly
introduce
users
to
new
concepts,
even
if
the
concepts
become
kind
of
you
know
the
right
way
to
do
things.
K
So,
to
give
you
an
example
of
something
like
this
in
the
framework
is
we
have
many
types
that
evolve
through
several
async
models,
and
you
know
it's
not
ideal,
but
it's
not
the
end
of
the
world
that
you
know
the
currently
proposed.
The
currently
recommended
async
model
is
not
always
you
know,
doesn't.
E
I
mean
I
understand
that
part
but,
like
I
guess
the
thought
experiment
is
more
along
the
lines
of
imagine.
We
would
have
built
binary
data
10
years
ago
and
we
would
have
built
it
with.
Let's
say
at
that
point
probably
data
contractualization
in
mind
yeah
and
then
the
question
is
okay.
If
you
had
this
type
now
in
the
framework
that
effectively
gets
preferred
treatment
to
you
know,
the
data
contradicts
emulsionizer
yeah.
Would
you
still
use
that
type
of
ninja
sdk
today,
or
would
you
build
your
own
just
because
the
default
is
wrong?.
K
No,
I
think
this
is
a
great
analogy.
What
you
just
said
so
imagine
that
it
was
built.
You
know
10
years
ago,
and
the
constructor
was
the
you
know:
xml
serializable
object,
but
by
that
time
users
already
learned
that
there
are
those
from
and
two
methods
and
they
were
seeking
json
serialization
and
they
discovered
that
it
would.
They
were
just
added,
as
you
know,
either.
K
K
Know
parameter
in
udan
I
I
think
that
would
be
fine
exactly
for
the
reason
that
I
mentioned
after
you
know
some
years,
people
already
know
how
type
works
when
there's
an
evolution
of
the
type
there's
a
blog
post
and
says:
hey
here's
a
new
feature:
here's
how
you
use
it
and
people
kind
of
understand
and
appreciate
why
things
are
done.
The
way
they
are
done.
K
B
It
takes
everyone
slightly
like
you
know,
five
minutes
longer
to
learn
how
to
use
it.
The
first
time
but
everybody's
on
the
same
keel,
and
you
don't
have
you
don't-
have
to
look
at
code
and
be
like
wait.
I've
never
seen
before
where
someone
called
the
and
didn't
say
that
they
were
using
protobuf
like
what
does
that
even
do.
Oh,
that
does
jason,
who
does
jason.
K
Anymore,
I
mean
it's
it's
it's
I
I
think
it's
true
that
for
new
people,
suddenly
they
if
they
never
knew
this
type,
but
how
many
people
either
the
type
will
not
be
successful
or
a
lot
of
people
current.net
framework
customers
will
will
know
this
type.
By
the
time
we
add
new
serialization
technologies.
B
E
I
yeah
I
mean,
like
that's
the
kind
of
thing
that
I'm
heading
it
as
well.
Like
I
mean
to
jeremy's
point,
I
mean
we,
we
do
know
from
usability
studies
that
people
have
a
problem
with
choices
right
and
I
feel
like
that
is
you
know
we
see
this
all
over
the
place
right.
We
I
don't
want.
E
L
E
Set
him
in
front
of
visual
studio
and
they
basically
asked
him
to
do
things
that
we
now
consider
modern
right,
you
know
create
a
new
asp.net
grab.
You
know,
create
a
console,
app
front
and
framework
that
sort
of
thing
and
like
they
just
failed
spectacularly
right,
and
that
is
basically
direct
outcome
of
what
jeremy
said
right
like
if
you,
if
you
have
15
years
experience
on
the
platform
every
time
you
learn
something
the
delta
is
small
and
then,
after
15
years
you
accumulated
so
much
knowledge
that
you
can
navigate
all
these
weirdnesses.
E
You
know
see,
but
if
you're
new
to
the
platform,
you
know
these
things,
don't
make
sense
to
you
and
then
to
jeremy's
point
in
three
years
from
now.
Maybe
if
the
thing
defaults
to
jason
feels
ridiculously
arcane
right
in
the
same
way
that
today,
we
think
xml
data
conceptualization
seems
ridiculously
arcane
right,
and
I
think
that
to
me
is
kind
of
the
problem
with
these
types.
Is
that
if
we
think
of
this
type
as
a
timeless
platform
type,
then
those
kind
of
positive
decisions
seems.
E
K
If
you
know,
let's,
let's
talk
about
their,
so
let's
talk
about
the
alternative,
because
I
think
we
have
you
know
we
have
to
trade
off
between
small
kind
of
you
know
words
that
potentially
will
be
there
in
the
future
that
I
kind
of
have
to
say
they
are.
They
seem
to
me
super
small.
They
are
not.
You
know
massive
problems
that
people
will
be
really
confused
about.
They
are
small
words.
I
I
grant
you
that
and
then
we
have
to
trade
it
off
with
the
the
alternative.
So
what
is
the
alternative?.
E
Well,
the
alternative
to
me
would
be
we
basically
say
you
know
we
make
all
the
things
like
civilization
that
have
heavy
policy.
We
make.
A
E
Statics
and
then
we
still
ship
the
type
today
with
being
hardwired
to
jason,
because
well
that's
the
only
thing
we
can
do,
and
then
you
know
in
two
years
from
now
when
we
actually
have
language
support
for
extension
aesthetics,
maybe
we
do
protobuf
as
the
same
thing,
but
no
the
nice
thing
for
the
consumer
is
depending
on
what
your
dependency
closure
is,
which
measure
sdk
would
include
protobuf.
Probably
anyway,
then
the
intellisense
will
look
exactly
the
same.
I
mean
there's
some.
E
You
know
minor
differences
with
extension,
statics
and
regular
aesthetics,
but
like
people
don't
have
to
think
about
this,
whether
they
say
from
json
or
from
protobuf
the
syntax
looks
the
same.
The
expressiveness
is
the
same.
It
feels
very
like
it
like
it
all
gels
very
nicely.
There's
not
this
deep
falloff
that
you
suddenly
have
oh
yeah.
Now
you
go
from
a
constructor
to
your
name
method.
You
have
to
kind
of
rewrite
the
code
right.
Every
time
we
have
these,
like,
I
guess,
changes
in
modality
in
which
you
operate
with
something.
E
That's
when
you,
when
you
tend
to
lose
people
right,
and
I
feel
like
that's,
okay
for
fringe
scenarios.
It's,
I
think,
less
okay
for
for
scenarios
that
we
think
are
core
right
and
I
think,
like
the
question,
is
in
three
years
from
now.
Do
we
still
believe
that
jason
is
the
99
scenario
and
I
think
the
evidence
suggests
otherwise
and
that's
why
I
don't
want
to
corner
myself
where
I
say
yes,
I
designed
for
usability
but
to
me
usability
also
in
two
years
from
now,
not
just
for
today,
right.
K
Well
so
I
still
stand
be
behind
you're
trading
off
a
small
word
for
a
massive
usability
problem.
K
Guarantee,
but
if
we
remove
the
object
constructor,
this
type
would
not
be
successful.
E
But
that's
I
guess
I
guess
my
question
is
like:
why
do
you
believe
that's
true,
because
now,
let's
say
you
do
a
fast
forward.
Three
years
from
now,
you
have
a
choice
between
json
and
protobuf,
and
the
the
fair
comparison
is
not.
You
have
a
person
that
has
used
to
type
for
three
years.
The
fair
comparison
is,
you
have
a
net
new
customer
that
is
exactly
as
new
as
today
for
binary
data.
E
K
No,
it's
not
because
if
we,
if
there's
another
format
that
is
so
common
that
we
want
to
make
it
the
default,
I
would
just
take
dependency
from
this
type
at
the
constructor
that
takes
object,
enum
value
that
switches
between
json
and
the
other
one
and
and
the
type-
and
there
won't
be
a
visibility
issue.
K
E
Think
I
think
the
problem
with
the
with
the
constructor,
I
think,
and
that's
the
thing
I
don't
have
data
on
which
I
think
is
the
thing
I
would
be
willing
to
test
is,
I
think,
if
you
have
no
constructors,
then
people
will
try
static
methods
before
but
like.
If
you
have
some
constructors,
I
think
people
will
assume
that's
the
only
way
they
can
construct
the
type
but
then
yeah.
I
think
I
buy
the
argument
that
your
problem
is
not
the
default
versus
non-default.
E
K
Yeah
and
also
the
additional
difficulty
to
what
you
said
is
that
we
cannot
remove
all
constructors
from
this
type,
because
it
will
always
have
a
default
constructor
and
it
really
confuses
people
because
they
basically
instantiate
it.
They
don't,
then
yeah,
you
know
if
it's
basically,
if
it's
a
class,
it
doesn't
have
a
constructor
we've
seen
it.
It
still
confuses
some
people,
but
some
people
after
a
while,
go
and
see
the
static
methods.
Unfortunately
for
strikes,
they
just
create
an
instance
of
it,
and
then
they
keep
searching
around
how
to
do
something.
With
this
instance
right.
B
But
I
think
that
if
it
only
has
a
default
constructor
like
somebody's
going
to
look
for
properties
or
set
methods
to
load
in
the
data
they
want,
so
that's
the
emo's
suggestion
of
everything
being
async
instance.
Extension
instance
methods
feels
I
mean
granted.
I
haven't
done
a
usability
study,
but
it
feels
to
me
like
it's.
You
know
like
a
10.
Second
roadblock,
not
a
oh,
my
god.
What's
going
on,
so
it
that's.
Why
I
liked
that
one
because
it
it
it
didn't
like.
B
Yes,
as
far
as
the
fact
that
it's
technically
immutable,
struct
and
and
all
this
is
sort
of
new
things,
but
from
the
user
experience
they
probably
don't
notice,
it's
a
class
versus
destruct
yeah,
the.
If
you
call
two
sets
it
throws,
but
you
probably
most
people
would
never
try
that
and
if
they
do,
we
had
it
throw
so
that
it
wasn't
a
mutable
struct
with
all
the
mutable
struct
consequences
and
like
to
me.
It
feels
like
that
it
it
has
good
growth
and
it
has
good
discoverability
yeah.
K
B
K
Yeah
so
so,
as
I
said
to
me,
this
type
becomes
so
ugly
and
so
like
it
has.
Basically,
we
just
added
three
different
usability
roadblocks,
and
I
agree
that
maybe
each
of
them
is,
you
know,
is
small,
but
it's
just
it's.
You
know.
The
end
result
is
super
ugly.
I
would
just
not.
K
I
would
just
ship
it
in
azure
car
at
that
point.
So
now
the
other
things
that
we
started
to
consider
like
small
tweaks.
You
know
adding
enums
and
whatnot.
I
think
they,
maybe
you
know
some
compromises.
We
should
consider
that
one.
I
have
to
tell
you.
I
would
just
like
give
up
on
trying
to
have
a
type
in
dcl,
so
I
thought
that
we
kind
of
and
it's
fine
if
you
say
that
you
know
you
don't
want
the
you
you
do
you.
You
really
are
set
on
this
mutable
type
with
set
methods.
E
Yeah,
I
think
I
think
the
question-
and
this
is,
I
think,
the
also
the
bias
that
we
have.
I
mean,
like
both
jeremy
and
I
are
more
thinking
about
like
what
does
it
mean
for
the
bcl
in
the
long
run,
but
that
is
a
you
know,
an
implementer's
concern,
not
a
user
concern.
I
think
to
me.
The
user
concern
is
kind
of
kind
of
reflected
by
what
I
said,
but
I
see
the
user
as
changing
over
time
and
I
try
to
create
a
version
that
is
uniform
across
time.
E
That
basically
means
yes,
I
will
I'm
I'm
accepting
hits
for
particular
users
at
particular
points
in
time
right,
but
I
try
to
create
an
average
over
time
which
is
very
similar
to
implementation
level.
Concern
in
my
opinion,
but
like
it's,
it's
not
entirely
disjoint
from
that
now.
The
question
really
is
like.
As
I
said,
I
I
think
this
tension
that
we
have
right
now.
Constructors
versus
factories,
I
think,
is
something
we
should
use
ability
to
test
anyways
because
I
think
to
me.
E
This
is
something
that,
if
we
do
that,
I
do
have
more
munition
to
talk
to
the
c,
sharp
team
and
say
I
really
really
want
extension
statics
and
his
usability
studies
have
proved
that
why
that
would
be
useful.
But
again
like
it's
it's
you
know.
If
the
utility
gap
is
genomics
between
constructors
and
static
methods,
then
there
wouldn't
be
enough
right.
At
that
point,
I
would
ask
for
con
extension
constructors,
but
like.
E
Well,
yes
or
async
constructors,
but
that
you
know
both
of
them
seem
untractable,
because
how
would
you
ever
have?
How
would
you
ever
resolve
conflicts
in
that
world
right?
But
I
I
think
the
question
becomes
is
like
you
know,
what
do
we
do
for
the
for
this
particular
design
moving
forward
like
I,
I
don't
know,
I'm
willing
to
fund
these
ways
to
study
from
our
end,
I
think
we
can.
We
can
probably
do
that.
E
I'm
just
not
sure
how
fast,
because
realistically,
we
probably
need
at
least
a
few
weeks
of
like
for
what
time
to
actually
get
people,
and
then
you
know
actually
do
the
study,
which
is
probably
going
to
take
a
few
days,
and
then
we
would
have
to
actually
take
that
data
and
decide
what
to
do
with
it.
But
if
you
want
to
ship
in
two
months,
that's
that's
a
bit
rough.
In
terms
of
timeline,
I
mean
the
type
isn't
big.
K
Yeah,
so
so
now
going
back
to
the
proposal
that
you
say
because
I
mean
I
have
to
tell
you,
there
are
like
several
alternatives
that
we
explored
and
some
of
them
and
to
me
are
not
acceptable
and
some
of
them
I'm
like
skeptical,
but
maybe
it's
fine
and
maybe
it
would
be
worth
you
know
if
you
think
that
to
test
it
to
kind
of
you
know,
have
more
data,
so
the
one
that
you
are
now
exploring
emo
is
to
remove
all
constructors
or
or
not.
K
We
have
that,
so
we
have
already
done
that
study
because
it
we've
done
several
studies
with
different
with
different
kind
of
tweaks
and
we
kind
of
the
shape
that
we
have
right
now
we
learned
about
it.
It's
like
I
can
show
you
the
whole
evolution
of
of
the
shape.
So
actually
we
had
what
you
just
said
and
the
end
result
was
the
following.
K
So
they
see
that
there's
binary
data
and
it
takes
basically
bytes
and
if
we
ask
them
in
usability
study
to
send
the
serialized
object,
they
think
that
they
have
to
serialize
manually,
which
defeats
the
purpose
of
the
type.
Basically
they
go,
and
you
know
instantiate
serializer
deal
with
all
the
problems
that
this
type
is
meant
to
be.
K
K
Moment
you
remove
all
constructors,
I
I'm
not
sure
if
we
have
this
study,
but
you
know
we've
been
doing
usability
studies
literally
every
week.
One
study
and
what
happens?
Is
people
get
confused
because
straight
is
tracks
have
constructors
and
they
instantiate,
and
then
they
get
completely
lost
because
they
don't
know
how
to
initialize
this
type.
So
it's
even
worse
like
if
they
I
grant
you
that
if
we
made
it
into
a
class,
what
happens
is
slightly
different?
B
Apparently,
using
the
extension
methods
means
we
have
to
turn
into
a
class
async
set.
No,
the
async
set
should
still
work
because
it'll
just
right
back
to
the
thing.
No.
F
F
F
B
You
capture
it
as
a
ref
this
you
do
all
your
async
work
in
a
helper
method
and
then
you
call
the
synchronous
set,
because
that's
all
these
things
are
doing
because
they
they're
ultimately
async
drains
into
a
synchronous
set.
So
I
think
you
can
still.
B
That's
yeah,
I
guess
that's
true,
all
right,
fair
enough,
so
so
extension
extension
methods
won't
solve
the
async
problem.
F
E
B
E
K
Well,
we
kind
of
you
know
wanted
to
keep
it
lean
unless
we
have
a
reason
to
make
it.
You
know
heavier
if
we,
if
we
feel
that
you
know
changing
it
to
it
into
a
class,
would
solve
some
problems.
I
guess
that's
that
would
be
acceptable.
E
F
K
E
B
K
E
E
And
basically,
that's
that's
what
I'm
saying
for
this.
I
mean
I
would
probably
give
them
by
the
way
that
the
same
semantic
immutable
array,
which
is
it's
just
a
reference,
equality
comparison
without
lying
on
for
the
underlying
array,
and
so
it
only
compares
for
the
same
sources
effectively,
and
that
seems
generally.
I
B
Fair
but
the
thing
like
the
building
it
from
a
span
means
there
was
a
copy,
and
so
the
only
way
you
would
have
the
same.
Underlying
array
is,
if
you
were
actually
the
same
instance
at
which
point
let
the
instance
of
quality
run
it's
faster
than
invoking
a
custom
method.
F
K
K
E
B
K
K
E
F
F
B
If
you
had
just
the
string
hello
and
someone
had
a
slice
of
hello
world,
they,
the
slice
of
hello
world,
doesn't
understand
it's
only
hello,
it
wouldn't
be
dupe.
It
would
keep
the
reference
to
hello
world
with
a
length.
K
F
K
F
E
E
I
mean
that's
the
general
problem
with
equality
is
that
people
have
different
notions
of
what
it
is.
I
mean
ugly
people
have
the
same
expectations
for
race
right
and
we
kind
of
taught
people
painstakingly
that
that's
not
what
they're
getting
yeah.
In
that
sense,
I
think
we'd
only
memory
will
only
span.
I
think
to
me
makes
sense
that
they
have
the
same
seminars
as
the
race,
because
that's
basically
what
they
are.
Okay.
K
K
K
K
Well,
type
error
is
one
way
to
model
this
behavior
yeah.
I
mean.
B
8.2
bytes
sequence
equals
b.2,
bytes
returns
true,
but
two
string
dot
equals
two
string
doesn't
return.
True,
therefore,
equals
doesn't
return.
True
feels.
F
F
E
E
Yes,
I
think
functional
people
would
disagree
with
you
on
that
notion.
That
type
hierarchies
are
a
good
way
to
do
discriminated
unions,
but.
E
They
also
give
you
a
tag
and
they
use
that
for
completion
matching
right,
which
you
don't
get
from
object
oriented
hierarchies
by
themselves,
but,
like
I
think
the
question
becomes
like
what
do
we
do
for
this
type
here
right.
I
think
if
to
me
object
orientation
here
seems
over
the
board
because
you
basically
never
care
right.
I
mean
unless
you
expect
people
to
say
you
know
things
like
if
binary
data
is
string,
binary
date
or
s,
and
then
s
dot,
original
string
or
something
then
maybe
but
like
presumably,
I.
F
Would
only
do
that,
I
I
expect
either
that
or
if
binary
data.content
type
equals
equal
string,
then
call
binarydata.2string,
I
mean
they're
equivalent-ish,
I
mean
clearly
you
all
have
performed
usability
studies
and-
and
I
haven't
so
you
would
know
you
know
what
the
trade-offs
are,
but
in
my
mind,
they're
exactly
equivalent.
I
don't.
E
Me
the
downside,
with
doing
what
you
suggest
levi,
is
that
you
like,
if
you,
if
you
think
this
to
an
end,
let's
say
we
have
like
six
or
seven
derivatives
of
binary
data
that
seems
fairly
heavyweight
for
something
that
you
probably
never
ever
want
to
access
like.
At
that
point,
I
think,
like
literally
just
exposing
properties
on
the
type
seems
cleaner,
because
then
you're
like
well.
If
you
really
really
need
this,
then
you
you
can
but
we're
not
polluting
the
system
name
space.
We
have
like
six
types.
E
That
seems
I
mean
we
could
also
have
nested
types
under
binary
data,
and
we
can
play
tricks
like
that,
but
I
feel
like
types
have.
A
higher
concept
count
cost
than
some
properties
on
the
type.
D
E
I
mean
in
fairness,
though,
like
I
think
kristoff,
you
can
probably
hack
that
in
two-string
today,
by
just
doing
some
smart
introspection
of
the
of
the
payload
like,
if
you
basically
say
the
first,
four
or
five
characters
are
all
within
the
text
range.
We
just
print
it
as
a
string
or
something
right.
That
would
probably
go
a
long
way.
K
E
K
F
Yeah,
so
if
I,
if
I
wrap
a
binary
data
around
a
string
for
instance,
and
then
I
send
that
off
to
to
the
azure
endpoint
like
the
only
bytes
that
are
actually
going
to
go
across
a
wire,
are
the
bytes
that
are
the
utf-8
representation
of
the
string.
You
lose
the
fact
that
it
was
created
from
a
string.
K
K
K
B
Well
because
it's
either
just
a
string
at
which
point
we're
just
taking
the
http
notion
of
content,
type
and
shoving
it
down
and
making
people
specify
it
when
they
only
care.
If
it
goes
over
the
wire
slash
now,
we
have
again
different
complicatedly
different
modes
of
the
object
or
it's
an
enum
at
which
point
the
type's
no
longer
extensible.
E
Well,
I
mean
I
would
not
go
that
far.
I
think
I
think
it's
reasonable
to
say.
Let's
say
we
would
have
a
content,
type
property.
That
say
that's
of
type
string,
because
that
I
agree
with
your
enum
would
be
bad
probably,
but
if
you
make
it
a
string,
you
could
imagine
that
all
the
constructors
that
take
binary
payloads
right
now
they
have
an
optional
parameter.
E
B
E
Well,
you
still
talk
about
some
bytes.
You
basically
just
say
like
you
have
attack
with
that
data.
That
tells
you
what
you
know,
what
that
bad,
what
the
binary
data
is,
which
I
think
still
to
me,
makes
sense
for
a
type
called
binary
data,
because
you
know
kristoff
gave
a
few
examples
where
that's
useful,
I
mean
content
type
or
mime
type
is
one
but
yeah.
Okay,
I
don't
know
like
it
doesn't
seem
to
me
like
you're,
not
extending
the
the
role
of
the
type
you
just
make
it
more
usable,
but.
K
B
E
So
I
can,
I
can
try
to
like.
I
don't
know
christoph
who
does
usability
studies
on
your
side.
I
can
talk
to
them
and
then
we
can
decide
how
we
want
to
schedule
this.
I
think
it
would
be
reasonable
for
us
to
test
the
design
that
I
sketched
to
just
see
where
this
is
because,
even
if
we
don't
use
it
for
binaural
data,
I
still
think
it
would
be
useful.
It's
really
to
study
for
us,
so
I'm
willing
to
fund
that.
E
Yeah,
basically,
the
design
that
I
currently
have,
which
is
you
have
no
constructors,
you
basically
are
forced
to
use
factory
methods,
slash
extension
methods
and
base.
So
basically,
this
would
be
this
design
here
with
just
statics
and
this
design
here
with
everything,
as
instance,
methods
and
then
see
how
people
fare
with
that.
B
Yeah,
I
mean
one
thing
that
would
be
hard
to
figure
out
how
to
do
in.
This
is
figure
out
what
it
would
mean
to
add,
protobuf
and
see
how
confusing
it
is
when
there's
like,
whatever
we
would
come
up
with
for
protobuf
or
some
other
technology
that
there's
now
one
thing
that
looks
slightly
different
than
the
rest
and
does
that
just
totally
baffle
people
or
not
well,.
E
K
Exactly
because
I
think
my
assumption
is
that
if
it's
some
critical
format
for
us,
we
wouldn't
be
afraid
of
taking
dependency
on
it,
and
if
it's
not
critical,
it's
fine,
it's
starting.
It's
static
methods
just
like
today,
things
are
static
methods
anyway,
so
you
don't
find
it.
As
you
know,
constructed.
E
Yeah,
the
only
answer
for
that
line
of
thinking
is
that
we
very
rarely
find
ourselves
in
a
category
where
we
can
decide
what's
critical,
it's
basically
things
are
growing
and
so
yeah.
Then
the
question
is:
when
is
the
right
time
and
then,
by
the
time
you
know
it's
critical.
Well,
you
ship
the
design.
That
is
the
ugly
one
right
and
then
you
don't
want
to
change
it.
Well,.
K
B
E
You
can't
okay,
let's
talk
about
that,
one,
because
I
think
that
one
is
also
a
thing
that
I
you
know,
as
you
can
see
here
by
the
header
like.
I
can
leave
this
open
but,
like
I
think,
no
matter
what
we
do,
we
have
to
ship
this
as
a
new
get
package
targeting
net
standard.
In
order
for
this
to
be
useful
for
the
azure
sdk
at
all
right.
E
So
then,
then,
if
we
do
that,
then
I
think
you
know
the
way
I
would
design
the
the
the
thing
at
this
point
is,
I
would
say,
it's
a
net
new
assembly,
it's
a
net
new
nuget
package,
it's
inbox
for
net
six,
but
it
basically
has
the
same
characteristic
that
immutable
collections
have,
which
is.
We
can
always
bump
the
thing
and
reference
a
new
version
and
replace
the
inbox
one,
because
then
that
means
the
api
service
isn't
frozen.
E
Hold
on
like
what
you
mean
yeah,
I
mean
to
me.
This
is
the
thing
I
already
talked
with
dan
about
like
that
to
me,
is
you
know
the
way
I
see
this?
Is
it's
it's
exactly
the
same,
azure
sdk
ask
as
jason.net2o
was,
and
I
have
an
action
item
on
my
site
to
basically
write
up
the
rules
of
the
the
rules
of
engagement.
If
you
will
and
basically
get
the
directors
to
just
green
light
that
so
we
don't
have
to
have
a
a
one-off
case
law
where
everything
these
things
are
happening
because.
E
E
By
default,
we
don't
ship
things
down
level
unless
we
have
a
partner
like
sdk,
that
for
business
reasons,
need
a
non-level
version,
and
this
one
I
mean,
given
that
it
comes
from
the
azure
sdk
like
to
me
it's
kind
of
like
a
no-brainer
like
if
we
ship
this
for
net
six,
only
we
might
as
well
not
ship
it
at
all,
because
it's
not
useful
to
them
right,
like
it's,
a
it's
a
pie
in
the
sky
thing
that
they
will
never
use
so.
B
E
B
E
That's
where
we
don't
feel
warm
and
fuzzy
about
this
thing
anymore,
because
now
it
has
all
this
complexity
that
we
have
right
now.
The
thing
with
binary
data
is
that
it
doesn't
have
to
go
to
system
runtime
right.
We
don't
have
to
do
any
crazy
type
forwarding,
because,
because
we
said
this
thing
is
a
high
level
type,
it's
a
it's
a
it's
a
leaf
node
in
our
dependency
graph
right.
It
depends
on
system
text.json.
It
depends
on
memory
of
t
and
all
the
other.
Sorry,
you
know
system.
E
memory
and
all
the
other
packages
we
already
have.
So
this
one
is
is
is
a
very
high
level
package
and
this
one
we
can
just
say
the
identity
refs
independently,
which
means,
if,
even
if
you
put
it
in
box,
we
can
replace
its
contents,
which
means
the
api
service
isn't
frozen.
We
can
add
new
things
over
time.
If
you
know
in
dot
net
seven,
let's
say
we
have
to
add
protobuf,
or
we
just
add
the
protobuf
constructors,
and
we
can
ship
it.net
standard
to
old
version
of
their
package.
E
It
also
has
those
constructors,
because
if
you
were
to
publish
this
to
a.net
6,
you
know
application
that
only
ships,
the
old
version
inbox,
you
replace
the
inbox
version
one,
but
it's
the
same
thing
as
just
from
text.json.
It's
the
same
semantics
as
immutable
or
metadata
reader,
because
it's
a
leaf
load
component.
E
If
we
ever
think
bind
data
has
to
be
type
forward
just
to
system
runtime
or
some
other
lower
level
assembly,
then
that
is
much
much
more
difficult
and
that's
why
we
really
don't
want
to
do
this
right
and
that's
why
you
know
span
basically
is
frozen
because
we
can't
add
members
to
spam
anymore.
For
that
reason,
but
that.
E
Case
here,
so
that's
why
I
feel
like
from
a
from
an
ubering
standpoint.
This
is
a
low
risk
thing.
We
know
how
to
do
it.
It
felt
squarely
with
the
pattern
that
we
have
validated
over
years.
Now,
it's
just
to
me.
The
only
controversial
bit
here
is
that,
yes,
we
ship
a
net
new
concept
for
an
old
platform
which
our
directors
generally
don't
like,
but
again
like
we
have
done
this
before,
because
you
have
a
partner
sure.
B
Sure
sure,
just
again
for
the
notion
of
extensibility,
it
means
if
we
feel
that
protobuf
or
cbor,
whatever
really
is
net
five
or
net
six
or
whatever,
only
that
we
then
can't
add
them
to
here.
We
have
to
the
two
decisions
become
coupled
together,
because
it's
strong
strongly
coupled
instead
of
extension,.
E
B
It
just
like
yeah
again
the
thing
that
I
like
about
the
extension
approach,
assuming
that
it
had
equivalent
usability,
is
that
it
does
decouple
a
lot
of
things
from
each
other.
It
lets
pieces
move
independently.
Yes,
it's
much
more
of
the
pay
for
play
that
people
think
they
want.
E
E
E
Okay,
with
the
fact
that
you
know
you
get
a
dependency
on
cbore,
which
they
never
use
right
and
the
answer
for
that
might
be
no
right,
and
I
think
that's
where
extensions
are
a
bit
more
nice,
because,
as
you
said,
it's
pay
for
play
don't
depend
on
it,
you're
never
deployed
it's
fine,
I
mean
yes,
the
linker
in
principle,
can
remove
those
things,
but
it's
always
weird
yeah.
If
it's
in
them
it's
hard
and
also
like
it
always
bugs
me.
E
If
we,
you
know,
dump
a
whole
bunch
of
garbage
into
the
output,
folder
and
then
say:
oh
yeah,
the
linker
will
take
care
of
it
because
it
always
seems
bad
to
inject
that
we
didn't
rely
on
to
be
removable.
So
for
those
things
I
think
it
makes
sense
to
remove
that.
But
again,
like
cyborg
doesn't
strike
me
as
super
likely.
I
mean
correct
me
but,
like
sure
seems
more
like
it's
just
that
we
happen
to
have.
B
It's
it's
just
a
it's
a
thing
that
I
can
use
as
a
concrete
example
of
we.
We
currently
shipped
it
as
as
net
core
family,
only
and
sure
that
we
would
then
have
to
go
backwards
and
then
find
out
if
we
had
messed
up
and
the
contract
can't
go
to
net
standard.
And
now
we
need
a
split
contract
which
already
complicates
the
package
right.
Like
there's
a
bunch
of
tightly
coupled
means
we
have
to
revisit
decisions
from
years
prior.
E
E
B
Right
but
there's
as
far
as
I
know,
there's
nothing
that
we
have
that
says
the
code
like
it
wouldn't
see.
The
code
paths
that
that
pulled
in
cbore
only
exist
in
these
switches
or
in
these
switch
statements.
Therefore,
it
has
a
dependency
on
this
field.
They
could
theoretically
write
it.
I
just
don't
think
they've
done
that
yet
and
it's
probably
I
don't.
I
have
no
idea
how
many
years
out
that
is
on
their
priorities.
E
Well,
but
that's
not
the
problem
right,
because
we
have
that
in
other
cases
right,
your
constructor
that
takes
object
and
type
has
the
same
problem
right.
The
linker
has
no
way
to
to
know
that
you
don't
have
to
retain
these
types
right,
but,
like
the
thing
is,
the
question
is
more:
like
is
idiomatic
code
linkable
right
like
if
you,
if
you
don't
write,
if
you
don't
read
an
enum
from
a
file
and
cast
it
to
an
end?
Is
the
linker
smart
enough
to
realize
that
the
answer
is
today?
E
No,
but
like,
could
we
envision
link
annotations
on
the
enum
that
would
make
that
possible
right,
because
I
would
agree
with
jeremy
like
if,
if
basically
the
inum
design
would
mean
you
can
never
link
out
that
might
be
okay,
if
there's
only
one
and
two
technologies
in
there,
that
becomes
more
of
a
of
a
liability
when
there's
like
four
or
five
right
and
then
the
question
is
now
we
have
to
retain.
You
know
all
the
serializers,
because
the
sdk
which
we
assume
everybody
will
ever
use
because
we
want
everybody
to
use.
E
Azure
no
depends
on
everything.
You
know
everything
every
technology
that
we
care
about,
that
might
be
wrong
right.
I.
F
E
Where
we
are
today,
but
like
the
point
of
this
exercise,
to
make
it
simpler
is
to
say
the
average
joe
can
turn
the
linker
on
and
it
doesn't
remove
that
he
actually
uses
so
the
end
of
the
the
resulting
app.
You
know
definitely
works,
but
also
it
is
not
ginormously
large
right.
So
we
want
this
to
be
path
of
success.
F
Yeah,
but
what
what
we
did
for
asp.net,
for
instance,
is
we.
We
have
a
very
clear
error
message:
that's
displayed.
If
you
don't
set
the
appropriate
link
or
options
that
says
hey,
you
need
to
go
back
to
your
project
json
and
set
this
exact
line
in
it.
Granted
it's
it
is
unclean
and
it
is
an
extra
step,
but
we
at
least
have
precedent
for
it.
If
it
really
came
down
to
it,.
B
F
B
But
it
would
be
the
case
that
the
azure
sdk,
if
they
ever
exposed
that
enum
as
an
input
from
any
of
their
public
methods,
then
they're
at
their
closure
level.
It's
still
not
provable
and
I
do
think
you
can
only
link
applications,
but
still
it's
did
it
ever
come
go
into
and
out
of
object,
it
lost
the
flow
everything's
in
the
graph.
Now
right,
like
oh.
K
Yeah
yeah,
I'm
skeptical
that
you
know
automatic
trimming
here
would
work
but
again
the
way
I
would
do
it
is
initially.
K
So
initially
they
are
just
an
external
package
and
then
we
can
pull
it
pull
them
in
if
they
become
super
critical-
and
this
is
going
to
happen
with
you
know,
50
formats
of
their
over
the
next,
you
know
10
15
years,
it's
gonna
happen
with
you
know
one
or
two,
and
I
think
we
can
afford
it.
Just
like
you
know
we
do.
They
take
dependency
on
utf-8,
16
and
probably
32.,
and
it's
not
a
big
deal.
Yeah.
B
Well,
it's
the
linking
stuff
would
work
if
everything's
distinct
methods,
because
it
would
see
you
never
called
a
method
that
used
json
serializer.
I
can
remove
it
like
after
I
removed
all
the
public
methods.
You
never
called
nothing
had
a
dependency
on
this
anymore.
I
can
drop
the
whole
library,
but
if
it's
an
enum
this
something
in
the
method
body
still
can't
talk
about
the
type,
so
it
stays
relevant.
K
K
E
K
E
Crystal's
argument
is
like:
if
something
is
successful,
you
like
your
chance
of
somebody
somewhere
using
it,
is
close
to
100
anyways,
in
which
case
you'll,
stop
caring
right
so
take,
for
example,
utf-8
and
utf-32
or
so
ut16utf8.
Like
you,
there's
no
apps.
You
can
realistically
write
today
that
would
link
one
of
these
sites
out
because
the
whole
stack
relies
on
both
right
and
so
at
that
point
you
basically
just
say
it.
E
We
just
pay
for
this,
because
it's
a
platform
feature
it's
always
there
and,
yes,
you
can
never
link
it
out
and
I
think
that's
I
mean
I'm
not
sure
that
I
would
buy
this
for
serializers,
but,
like
I
like,
I
can
buy
this
argument
in
principle
where
yeah
it's
also
not
a
huge
list.
I
mean,
even
if
we
say
we're
very
generous
realistically,
this
enum
will
probably
have
three
members
right
and
I
think
that
seems
fair
enough
absorbable.
E
I
I'm
more.
The
problem
I
have
is
this
more
like
the
interim,
because
I
feel,
like
we
experiment
a
lot,
and
so
things
will
show
up
and
then
the
question
is
like
what?
What
does
that
look
like
right?
So
I
feel
like
on
our
team.
Like
the
complexity
we
have
to
deal
with,
we
still
have
to
design
extension
methods.
We
have
to
design
the
packages
you
have
to
ship
them
and
we
have
to
tell
users
how
to
compose
that,
because
we
will
experiment
with
you
know:
let's
say:
seaboard
protobuf,
b
sauna.
E
K
But
so
I
I
can
put
you
know
the
pattern
that
I
would
see
is,
let's
say,
there's
a
new
package
with
seabor
serializer
and
in
this
package
there
would
be
an
extension
method
to
object
correct.
So
it's
an
extension
method
that
immediately
appears
on
binary
data
as
an
as
a
extension
method,
and
then
you
have
siebel
serializer
dot,
create
binary.
You
know,
create
binary
data
or
serialize
to
binary
data,
and
you
pass
an
object.
It
gives
you
binary
data.
So
yes,
initially
they
are
in
separate
package.
E
K
Not
yet
at
the
top
of
the
you
know,
usage
list,
and
but
you
you
grabbed
it
and
you
have
those
two
methods.
You
can
very
quickly
create
binary
data
and
you
can
get
you
know,
object
out.
Then
let's
say
sieber
becomes
a
d
format
for
network
exchange
and
then
we
just
say
you
know.
Well.
We
now
take
dependency
from
this
package
to
the
silver
package,
and
you
know
we
just
pull
it
in
basically
right.
B
B
B
K
B
Yeah,
like
I
would
really
like
the
current
things
that
are
from
object
into
object
to
say
the
word
json
in
them
somewhere
and
then
we
know
understand
what
the
pattern
is.
Its
new
types
get
their
name
in
that
spot.
That
works
for
an
extension
method.
It
works
for
remove
the
static
locally.
Like
it's
a
it's,
it's
a
pattern
we
can
follow.
B
And
yes,
we'll
have
this
weird
thing
in
the
middle
that
cbor
serializer
has
cbor
serializer.two
binary
data
that
then
later
people
would
expect
that
they
would
call
binarydata
from
cbor
object
and
or
from
object
as
cbor
or
whatever
right,
like.
K
B
L
K
K
E
E
B
If
it's
the
constructors
and
factory
methods
with
new
technologies
being
async
methods,
the
from
doesn't
matter
because
the
only
time
you
can
get
the
from
is
to
actually
go
edit,
this
class
and
the
twos
yes,
you
could
have
a
the
newton,
soft
json
scenario.
You
would
have
to
put
some
other
word
in
there
to
indicate
you
wanted
the
the
newton's
off
json,
equivalent
or
newton's
off
jason,
to
do
the
processing
instead
of
the
built-in
one
but-
and
I
don't
think
that's
terrible
because
we
would
just
like
we
would
have
named
it
whatever.
E
I
mean
it
makes
it
a
little
bit
shitty
if
those
things
go
in
box
now,
because
the
first
person
then
like
let's
say
jason-
would
have
been
an
extension
today
and
then
we
move
it
inbox
now.
Well,
yes,
now
you
always
have
to
use
the
static
method
invocation,
which
kind
of
defeats
the
purpose
right,
but
I
feel,
like
that's,
probably
not
very
likely.
B
Well
or
you
just
make
well
if
it
went
inbox
in
order
to
hit
your
the
previous
one,
you
were
calling
you'd
have
to
call
with
the
static
invocation
or
you
make
a
local
extension
method
with
a
different
name
that
forwards
to
the
right
previous
extension
method.
G
L
K
B
K
B
Like
I,
I
would
really
like
whatever
we
pick,
that
we
we
have
a
suggestion
for
here's,
what
here's,
what
you
do
to
add
a
weak
dependency.
Here's
the
pattern.
We
recommend
you
follow
for
if
you're
hooking
up
a
protobuf
serializer
into
this.
This
is
the.
E
B
This
is
what
you
should
call
the
the
two
method.
This
is
what
you
should
call
your
local
from
method
and,
if
we
add
the
from
directly
on
the
type
later
then
they're,
they're,
aliases
and
right,
like
in
fact
our
new
from
would
probably
just
call
their
existing
static,
but
like
these
are
the.
K
E
B
Indeed,
but
it
would
be
man,
I'm
using
the
json
or
I'm
using
the
the
protobuf
serializer
and
it
produces
by
oh
hey:
look.
They
also
produced
one
that
produces
binary
data,
so
I
don't
have
to
just
wrap
the
call
myself
I
mean
granted
it's
just
rapping
to
call
itself,
but
the
but
figuring
out
what
the
pattern
we
think
that
they
should
do.
The
static
extensions
makes
it
so
much
easier
because
you
would
just
static
extension,
the
correct
from
and
then
we
would
never
forward
it.
E
B
Right
it
would
be.
You
know
that
protobuf
serializer,
we
expect
it
to
have
a
a
two
binary
data
method,
whether
it's
instance
or
static,
depending
on
how
the
serializer
works
and
and
then
that
later,
if
it
becomes
a
tightly
coupled
or
we
get
static
extensions,
then
we
add
the
from
object
as
protobuf.
E
K
K
K
K
Because
we
want
to
optimize
for
things
in
box
being
super
usable
just
like
when
you
buy
a
car,
the
radio
is
built
in
works,
you
have
buttons
and
everything
works
awesome
if
you're
not
happy
with
the
stereo,
and
you
want
to
install
a
big
subwoofer
in
the
trunk,
and
you
know
various
things
you
are
willing
to
put
up
with
a
bit
of
learning,
you're
grabbing
a
component.
You
know
external
component
package
and
and
you're
willing
to
put
up
with
some
level
of
additional
difficulty.
E
K
Well,
the
reason
for
it
is
that
so
let
this
type
that
I
have
on
the
screen
looks
like
a
normal
type
in
isolation
and
it
works
as
an
extension
or
a
helper.
So
now,
let's,
let's
try
to
rename
it.
I
can
tell
you
that
we
cannot
rename
the
methods
on
binary
data,
because
we
also
usability
studied
that.
In
fact,
we
use
ability
studied
calling
those
two
methods
serialize
and
deserialize,
and
it
was
a
complete
failure.
K
K
Yeah
correct,
but
you
know
the
others
were
called
from
into
like
string
and
and
so
on
and
so
on.
It
was
just
complete
failure,
so
we
discovered
that
if
we
named
all
methods,
all
methods
are
called
now
from
and
to
suddenly
the
problem
went
away
because
people
basically
just
either
look
at
static
methods,
or
instance,
methods
find
that
you
know
there
are
only
instance,
methods
called
two
and
then
type
two
and
then
see
all
the
options
and
select
one
of
the
options.
K
E
B
K
External
component-
I
I
you
know,
I
I
look
at
that
component.
It
has
the
serializer
and
has
those
extension
methods,
or
I
looked
up
at
some
code
sample.
I
you
know
I
I
think
people
will
be
fine,
on
the
other
hand,
renaming
these
methods.
So
now
the
the
question
is:
can
we
rename
those
methods
and
is
that
what
you
are
proposing
that
we
call
them
to
and
from
yeah.
E
So
I
mean
like
so
rename
the
second
occurrence,
json
serializer,
because
you
already
shipped
that
one
right
so
like
I
think
the
json
status
is
a
good
example
already
have
still
smd
serialized
on
json
sterilizer,
and
so
I
protobuf
already
shipped
as
well.
So
I
I
think
the
vast
majority
of
steelers
that
we
would
plug
in
have
already
shipped,
so
they
have
some
sort
of
method
today
that
allows
customers
to
serialize
and
deserialize
yeah,
and
I
think
what
my
recommendation
for
those
people
would
be.
E
If
we
don't
have
extension
aesthetics,
I
would
say,
basically
have
a
method
name
that
has
that
basically
just
suffixes
those
with
binary
data.
So
I
would,
I
would
say,
if
you
like,
if
json
wouldn't
be
built
in,
you
would
say:
json
serializer,
dot,
serialized,
binary
data
or
dcli
is
binary
data.
And
then
basically,
you
just
have
new
methods
that
know
either
return
or
or
take
a
binary
data
instance.
E
K
E
E
L
B
E
Hold
on
so
the
first.
The
other
thing
I
did
mention
is:
I
would
not
make
an
extension
method.
I
would
just
say
both
are
just
static
methods,
because
we
can't
get
extension
statics.
It
seems
weird
to
me
that
one
direction
is
off
of
binder
and
one
is
not.
I
would
just
be
consistent
and
say:
well,
you
can
do
a
binary
data,
but,
like
you
basically
don't
get
to
yeah,
you
don't
get
extensions.
Basically
I
would
I
would
not
do
half
of
the
thing
I
would.
I
would
do
symmetric,
behavior
and
say
yep.
B
E
E
B
E
It
just
seems
weird
to
me,
like
I,
never
understood
this
desire
to
have
it
in
one
way,
but
not
the
other,
like
I
I
like
symmetry,
because
it
basically
makes
my
apis
consistent,
but
maybe
I'm
the
outlier
I
yeah.
I
would
just
say
if,
if
you
have
extension
statics
like
if
sorry,
if
we
had
extensions
test
aesthetics,
I
would
totally
do
this
differently.
E
But
I
guess
my
point
is
that
the
question
is
also
like,
regardless
yeah
so
like,
given
that
we
don't
get
extensions
for
one
side,
I
would
probably
not
do
the
other.
That
would
be
my
take
on
it
and
I
would
say
if
we
don't
have
them,
then
the
question
is
how
how
do
we
want
seabor
and
protobuf
to
support
binary
data?
So
customers
don't
have
to
write
the
glue
code
and
I
would
say,
whatever
methods
you
currently
have
suffix
it
with
binary
data
and,
like
that's
the
the
same
place.
E
K
E
B
E
Guess
I'm
going
a
step
further
like
I
would.
What
I'm
pushing
for
is
whatever
entry
points
the
serializer
currently
has,
whatever
your
method.
Names
for
cls
and
dclis
are
just
duplicate
them
and
suffix
them
with
binary
data,
and
that's
your
entry
point
because
I
mean
I
think,
for
the
most
part,
people
don't
build
a
net
new
type
just
to
support
binary
data
right
they
will.
They
will
have
already
entry
points
for
their
serializer
and
they
will
just
add
new
methods
there
and
that
might
be
static
methods,
which
is
the
case
for
our
serializer.
E
There
might
be
instance,
methods
which
is,
for
example,
the
case
for
json.net,
because
you
can
you
up
the
serializer
and
then
you
call
them,
and
so
that's
what
I
would
expect
them
to
do.
K
Correct
so
basically
you're
saying
that
that's
why
I
was
saying
I
like
number
one,
because
in
isolation
it
just
looks
like
a
normal
methods
on
serializable.
E
K
E
B
E
A
K
B
E
Right,
which
is
why
I,
I
would
say,
I
think,
pattern,
number
one
is
probably
the
most
pragmatic
one,
because
basically,
what
we
are
saying
is
whatever
zealous
entry
points
you
have.
You
just
have
corresponding
versions
that
take
binary
data
or
produce
binary
data,
and
I
think
that's
probably
what
what
serializer
authors
will
most
likely
end
up
doing.
B
If
you
know,
let's
say
protobuf,
does
this
and
then
later
protobuf
becomes?
Excuse
me
the
the
de
facto
thing
that
jason
has
this
instance
member
on
binary
data
that
no
one
ever
wants
and
protobuf,
which
is
what
everyone
wants.
You
have
to
call
from
a
static
call
on
protobuffy
serializer
right,
and
that
just
feels
weird.
K
E
E
But
I
mean
if
we
look
at
you
know,
let's
just
look
at
our
json
apis
right,
because
we
already
have
a
serializer
method
and
produces
a
string
right.
So
if,
if
we
just
make
the
conversions
from
and
to
buy
and
data
better,
we
already
talked
about
having
an
implicit
conversion
from
span
and
with
only
memory.
B
E
You
don't
have
to
have
the
serializers
themselves
support
binater
directly.
At
that
point,
the
only
thing
you
would
consider
doing
is
if
we
had
an
extension
pattern
to
directly
inject
those
methods
into
biodata
to
improve
usability,
but
there
really
isn't
any
gains
for
making
it
easier
for
people
to
construct
the
binary
data
for
music.
E
F
E
E
So
public
service
announcement,
my
girlfriend
just
went
on
a
vacation
and
some
guy
had
a
mana
accident
and
he
got
bruises
on
the
abdomen
and
they
just
thought
that
you
know
bruising
in
the
abdomen
just
means
he
hurt
himself
a
little
bit
if
you
ever
have
somebody
with
bruises
on
the
lower
part
of
the
back
or
the
abdomen,
always
always
take
them
to
the
hospital,
because
you
don't
know
whether
there's
any
internal
bleeding
going
on
and
so
apparently
in
his
case
he
injured
his.
E
E
K
E
E
But,
like
that's
the
thing,
but
in
germany
we're
not
shy
of
doing
that.
The
only
thing
where
you
might
not
want
to
go
is
because
you
have
to
wait
in
line
for
40
minutes,
but
in
the
u.s
it's
like
well,
am
I
willing
to
shell
out
one
and
a
half
k
for
them
to
tell
me
that
I'm
fine,
so.
K
G
K
I
K
E
So
why
can't
we
inherit
yours?
Because
I
guess
all
your
ships
in
in
the
azure
name
space
is
that
where.
E
B
Serializer
seems
like
a
thing
that
would
be
very
easily
bass,
cluster
interface
or
or
whatever
like
really
it's
the
because
it
doesn't
have
to
be
the
serializer
right.
It's
because
I
think,
like
json
serializer
is
static,
but
you
would
but
it
has
the
settings
and
stuff,
so
it
would
be
a
configured
serializer
instance
I
mean
we
wouldn't
bury
all
that
stuff
in
the
name
but
like,
but
yes
you,
you
have
an
object
that
is
set
up
to
serialize
something,
and
then
you
throw
the
thing
at
it.
Now
we
need
to
define.
B
Does
it
support
generic
at
the
call
side
or
is
the
the
generic
what
you
should
have
done
at
the
instantiation,
and
it
already
knows
what
type
it's
doing
you
do
end
up
with
complicated
like
where
does
payload
discrimination
come
in,
but
from
a
simple
syntax
perspective?
It's
I
have
some
some
bytes
or
some
text
go
and
or
I
have
an
object.
You
already
know
what
you're
supposed
to
produce
give
me
the
bytes
or
the
text.
E
But
take
our
json
one
right.
I
think
it's
very
reasonable
to
take
our
json
study
class,
make
that
a
regular
class
and
have
a
public
with
only
instance
field,
effectively
or
property
for
that
matter,
and
then
you
know
this.
The
the
statics
just
become
shorthand
so
about
what
we
do
on
regex,
where
you
can
either
instantiate
a
reject,
so
you
can
just
call
static
methods
on
it,
and
then
you
know
it's
very
simple.
B
E
K
Because
we
basically
concluded
that
serializers
need
to
be
loosely
basically
dynamic.
K
K
E
Yeah,
I
think
the
the
conclusion
we
had
with
with
the
earlier
discussion.
I
think
it
was
the
extension
methods
valid
for
http
client,
which
also
had
object
and
type.
We
ended
up
doing
both
because
the
conclusion
was
yeah.
There
are
some
cases
where
you
don't
have
the
type
and
then
it's
fine
you
just
pay
for
that,
but
like
in
many
cases
you
do
have
the
type
and
then
you
just
still
benefit
from
the
linkability
or
just
also
run
temper.
L
L
L
Actually
is
I
I
guess,
the
reason
is
that
I'm
concerned
that
on
a
dynamic,
serialized,
class
or
interface,
whatever
that
is,
could
invite
scenario
where
you
know,
people
deserialize,
with
the
type
being
informed
by
the
payload,
which
is
known
to
have
security
implications.
E
I
mean
I
mean
the
the
thing
with
like
serialize,
with
the
with
the
type
payload
was
more
like
in
asp.net.
The
problem
that
they
have
is
that
because
of
di
and
other
things
in
many
cases,
there
is
no
static,
call
site
that
wires,
the
user
code
to
the
framework
code,
and
so
what
they
end
up
doing
is
they
have
to
do.
B
E
B
E
Yeah
one
other
question
I
had
was
like
for
liking
in
your
world
kristoff:
where
do
you
put
the
json
options?
Are
they
going
to
the
constructor
to
the
object,
realizer
or
like?
Where
are
they.
K
Yeah
yeah
you.
Basically,
the
idea
is
so
I
now
this
copied
and
pasted
the
object
serializer
that
we
shipped
this
is
its
shape,
and
basically
the
assumption
is
that
if
you
want
to
specify
options,
you
pass
them
to
the
constructor,
because
they
usually
options
are
specific
to
the
type
of
the
serializer.
B
Yeah
their
state
on
that
instance,
whether
it's
constructor
state
or
a
settable
property
collection,
or
you
know
whatever
it's
again
and
that's
what
xml
serializer
did
it's.
They
had
a
bunch
of
stuff
that
were
options,
and
once
you
build
it
now
you
just
call
d
serialize
and
give
it
the
object,
and
it
gives
you
the
whatever
text,
I
guess
and
sorry
dc
realize,
gives
you
the
object
here
always
gives
you
the
text
and.
K
K
E
K
E
B
G
B
Would
just
take
one
of
those
as
a
constructor
argument
and
now
again
you
have
the
you
called
new
json
serializer
of
t
ooh,
which
would
be
a
side
type,
and
then
you
gave
it
the
the
serializer
options
like
it's
now.
This
is
now
an
object
that
can
that
produces
this
particular
kind
of
t.
E
K
But
I
would
do
this
honestly,
I
guess
still
seeing
my
screen.
I
D
I
K
K
L
K
E
K
Yeah
it
was
copy
and
paste
okay.
So
there's
basically,
I
think.
K
E
B
I
mean
I'm
not
sure
that
if
we
have
easy
singletons
for
or
easy
factories
for,
json
and
xml,
I
don't
know
that
the
enum
one
buys
a
lot,
but
that's
a
that
would
be
a
discussion
for
a
later
date.
E
I
mean
I
don't
know
like
you
could
imagine
that
maybe
objects
are
sits
so
high
level,
maybe
that
one
can
have
them.
But
then
you
have
the
same
problem
as
before.
You
just
tie
everything
together
again,
which
ago
is
the
same
problem
that
the
enum
has
except
harder
to
be
traced.
B
E
K
For
for
async,
yes,
it's
async
and
kind
of
maybe
parity
after
people.
You
know
learn
that
there
are
those
static
methods.
They
are
not.
They
basically
can
now
say.
Okay
from
now
now
on
I'm
going
for
starting
methods
all
the
time
and
it's
everything
is
there
basically
the
static
methods,
the
philosophy
we
actually
discussed
it
on
the
on
our
team,
the
philosophy
was
static.
Methods
are
the
fully
complete
set
of
features
that
this
thing
thinks
has
and
then
something
they
are
just
helpers.
E
B
B
Right,
but
I
I
can
understand
where,
if
you
had
you
know
so,
the
all
the
ones
that
look
like
read-only
span
of
bite
as
constructors
and
then
everything
else
was
frums.
I
can
completely
see
people
never
noticing
the
froms
on
that
one
yeah,
but
it's
when
there's
no
nothing
other
than
a
default
constructor.
That's
when
I
think
that
going
back
to
the
either
all
set
extensions
or
static,
froms
or
whatever,
like
that.
B
That
immediately
shows
up
as
what
should
I
do
now,
if
it's
a
class-
and
it
has
no
public
constructors
at
all
and
new-
is
a
syntax
error,
then
they'll
find
the
froms
really
quickly
you've,
you
forced
them
down
in
down
one
pattern.
So.
E
E
I
mean
it
might
sound
weird,
but
but
I
I
do
believe
that
would
be
a
useful
thing,
because
you
can.
The
problem
is:
if
yeah
you
can
often
do
so.
People
want
by
just
looking
at
what
they
did
right
and
it's
like.
Oh
yeah,
I
see
you
have
a
new
statement
of
binary
data.
That's
not
going
to
fly,
you
have
to
call
it
one
of
those
from
managers.
E
It's
the
same
one,
it's
the
same
thing.
Basically
the
uanalyzer
gets.
So
if
something
doesn't
get
bound,
you
actually
get
an
error
symbol.
So,
like
you
can
so
you
can
look
at
new
statements
and
the
new
statement
is
bound
against
the
bina
data
type.
It
just
doesn't
find
a
constructor
right,
and
so
you
can
you.
A
E
Totally
do
that
relatively
easily.
The
problem
is
more,
like
you
know,
get
two
errors
right,
because
the
compiler
will
not
shut
up
right.
It
will
still
give
you
the
error
for
button
data,
so
you
have
to
make
sure
that
your
error
message
pops,
but
anyway,
like
I
think
it's
just
one
thing
we
could
explore.
I
think
the
the
it
just
I
don't
know
like.
E
E
That
seems
very
natural
to
me
and
then
the
other
problem
that
I
have
is
with
async.
I
I
fundamentally
hate
this.
Oh
you
know
you
want
to
do.
Oh
now
I
take
a
stream
that
is
actually
not
from
memory.
So
now
I
want
to
make
it
async,
and
then
you
have
to
rewrite
your
code
again
right.
It
seems
like
the
constructor
is
leading
people
down
almost
the
wrong
path,
because
growing
that
thing
is
basically,
you
have
to
delete
the
code
and
you
know
retype
it
with
aesthetic
invocation
right.
It
seems
unfortunate.
B
Yeah,
I
would
really
like
that
there
be
only
one
correct
way
of
doing
things
and
so
again,
if,
if
we
had
a
usability
study
that
said
that
people
absolutely
totally
fell
on
their
face
with
this,
when
it
was
no
public
constructors
and
or
only
a
default
constructor
and
that
they
had
to
use,
sets
or
static
froms,
then
I'm
totally
willing
to
look
at
the
data,
but
from
a
conceptual
thing
it
does
feel
like
the
answer
is
well.
B
The
constructors
are
here
so
that
you
find
that
you
can
use
this
type,
but
really
we
immediately
want
you
to
learn
to
call
the
froms,
which
effectively
means
we
obsolete
all
the
constructors
so
that
you
or
you
know,
put
the
analyzer
with
a
warning
of
like
you
should
really
call
this
other
thing.
Instead,
what
you
wrote
compiles,
we
just
don't
like
it.
It's
not
idiomatic
and
that
feels.
K
E
Yeah,
the
problem,
I
think,
isn't
that
I
think
the
problem
is
more
the
you're
kind
of
boxing
them
you're,
basically
leading
them
you're,
leading
them
to
a
room
that
you
then
immediately
tell
them
that
there's
more
to
discover
elsewhere,
and
then
you
have
to.
Basically
you
can't
go
from
that
room
anymore.
You
have
to
basically
step
back
to
the
root
and
then
take
a
different
path.
That
is
the
thing
I
don't
like
about
it
like.
I
think
it's!
Okay,
if
you
would
say
you
know,
there's
simpler,
overloads
and
there's
more
complicated,
overloads.
E
Those
seem
more
like
they're,
just
more
doors
in
the
same
room
that
you
know
can
see,
but
you
never
have
to
walk
back.
Do
you
know
what
I
mean
like
basically
by
saying?
No,
if
you
want
to
do
async
well,
you
have
to
walk
back
instead
of
doing
a
constructor.
You
have
to
call
it.
You
know
aesthetic
method
instead,.
E
K
Your
assumptions
and
I'll
tell
you
what,
in
the
proposal
what
they
think
methods
are
for.
They
are
so
for
so
obscure
scenario
that,
like
we
kind
of
don't
care
that
people
don't
discover
those,
and
so
I'll
tell
you
what
the
scenario
is.
The
scenario
is
that
some
serializers
in
the
course
of
serialization
they
do
io.
K
It's
not
that
because,
basically,
we
serialize
to
to
memory
stream,
so
async
is
kind
of
not
important.
The
thing
is
that
there
are
some
serializers
that,
during
the
course
of
serialization,
they
do
kind
of
side
io
an
example
would
be
avra
serializer.
That
goes
into
schema
registry
and
retrieves
the
schema,
but
those
are
so
obscure
scenarios
that
you
know.
Basically,
what
we
would
be
doing
is
to
make
it
more
consistent
and
make
all
obscure
scenarios
and
extension
methods
and
everything
be
the
same.
We
would
remove
constructors,
which
we
know
is
a
bomb.
B
K
B
And
that
stream
is
if
it's
a
file
stream
or
a
memory
stream,
if
it's
a
file
stream
created
by
anybody,
who's,
not
jeremy,
kuhn,
it's
a
synchronous
stream
and
therefore
it
doesn't
matter
which
one
you
call.
But
if
at
the
moment
it's
a
network
stream
or
a
jeremy
kuhn
created
file
stream,
then
it
might
be
actually
asynchronous
and
doing
actual
asynchronous
work.
B
And
now
you
may
have
left
that
one
out
of
a
out
of
the
constructor
pattern,
because
the
synchronous
one
in
stream
is
probably
not
the
one
you
want,
so
that
the
mainline
scenario
on
that
one's
async
and
the
sync
one's
there
just
for
sync,
a
parody
for
async
methods,
but
but
that
one
immediately
has
the
oh.
I
have
a
stream.
B
I
guess
I
have
to
drain
it
myself,
because
I'm
looking
at
the
constructors,
I
don't
realize,
there's
a
from
that,
will
do
the
work
for
me
and
why
can't
it
do
the
work
for
me
right
and
it's
like
well,
it
does,
but
we
have
these
two
patterns,
one
of
which
is
80
covering
and
the
others
100
covering
and
you're
in
the
20.
Sorry,
it
just
feels
weird,
like
I
don't
know
that
we
have
too
many
types
that
have
both
constructors
and
static
froms.
K
E
Yeah
to
me
the
I
mean
again
like
I,
I
have
a
hard
time
believing
that
people
struggle
entirely
through
static
methods,
if
there's
only
static
methods,
because
I
I
can't
think
of
something,
but
we
have
a
fuckton
of
like
properties,
at
least
where
you
don't
ever
need
up.
The
thing
right
encoding
comes
to
mind
and
other
things
like
where
that's
the
pattern
you
do
things
with,
but
I
yeah
I
mean.
I
understand
crystals.
K
K
So
it's
not
that
you
know
if
they
tried
the
constructor
discover
that
there
is
no
constructors.
They
are
like.
Okay.
If,
since
there
are
no
constructors
for
sure
there
is
a
method
to
you
know
a
static
method,
then
it
wouldn't
be
a
problem.
The
problem
is
that
people
learned
that
there
are
many
types
you
cannot
instantiate
it
instantiate
them.
You
kind
of
have
to
use
some
other
way.
K
You
know
they
may
be
a
types
that
only
are
returned
by
something
else,
so
a
non-trivial
number
of
people
would
try
to
instantiate
their
type
if
they
cannot,
they
just
give
up
and
they
just
okay.
Well,
I
have
to
you
know
I
have
to
somehow
figure
out.
Maybe
it's
returned
from
something
else.
Maybe
it's
an
abstract
class
and
they
don't.
You
know
notice
that
it's
not,
and
so
it
is
a
bomb,
and
I
I
I
don't
think
that
the
reason
to
introduce
the
bump
is
strong
enough.
L
B
E
Sure
we
do
no,
we
do.
We
do
do
that
right,
but
the
way
we
usually
think
of
these
is
not
like
alternatives
to
the
exact
same
thing.
We
usually
think
of
those
as
usability
bridges
right.
So,
for
example,
there
really
isn't
a
reason
why
you
need
to
use
the
file.static
apis
at
all.
You
can
just
new
update,
write
the
correct.
You
know
thing
you
can
just
new
up
a
stream
reader
passing
a
path
right
and
then
do
the
thing
yourself.
E
E
Well,
you
probably
look
for
file
dot
and
then,
oh,
you
see
a
method,
and
I
know
you
see
that
gives
you
back
a
stream
reader,
and
now
you
learned
about
stream
reader
right
so
like
now,
you
you
discover
effectively
the
way
you
can
do
things
right
and
that's
kind
of
the
same
here
I
mean
you
could
argue
that
the
constructors
are,
you
know
you
just
expect
constructors
to
be
there.
You
find
them
and
then
later
on,
you
say,
oh
there's
other
static
methods
on
the
same
type
that
do
more
stuff.
E
E
B
E
B
F
B
B
E
Yeah,
I
think
that's
yeah.
I
think
that's
a
good
observation.
I
think
the
the
it's
the
same
concept
as
just
different
mechanics
to
doing
the
same
thing
on
the
same
concept
does
seem
a
bit
redundant.
I
agree
with
that,
but
not
only
redundant.
I
think
it
literally
like
it
feels
like
you're,
really
leading
you
along
the
wrong
path
right.
It's
like
oh
and
use
the
constructor,
but
then
you're
telling
me
it's
actually
the
static.
I
should
probably
be
using
that
that
seems
odd.
B
Yeah-
and
so
it's
not
again-
I
mean
I,
I
see
the
value
in
this
thing,
and
but
the
the
trouble
is
the
at
the
best
value
we.
We
have
to
pick
some
general
rule
and
like
look
the
other
way,
because
we
do
have
a
lot
of
you
know
some
decoupling
things
which
are
coming
from
like
linker
stuff.
We
have
some
if
you're,
having
two
different
ways
of
doing
it.
K
K
Like
we,
we
often
have
the
design
where
there
is
a
kind
of
very
general
and
powerful
way,
and
then
we
have
helpers
and
yes,
they
duplicate
functionality,
and
we
say
too
bad.
We
we
we
select
defaults.
We
select,
we
add
helpers
because
we
want
to
have
both
power
and
helpers
that
provide
usability.
B
Right,
but
I
think
generally,
that's
when
you
have
a
high
level
versus
a
low-level
thing
or
it's
file
versus
file
stream,
that
one
of
them
is
about
the
noun
that
you're
looking
for
and
another
one's
about,
the
technology
that
you're
using
to
implement
it,
but
having
a
static
and
a
constructor
on
the
same
type.
Just
feels
to
me.
That
feels
I
understand
we
would
do
it
for
usability
and
discovery,
but
it
feels
like
people
couldn't
make
a
decision
and
said,
let's
just
ship,
both
things,
but
there's
no
difference
in
concept.
K
No,
no,
no,
I
I
so
I
I'm
not
sure
this
is
so
I
I
agree.
We
we
don't
want
something
that
we
cannot
explain.
What's
the
reason
like?
Oh,
we
didn't
have
reason,
it's
a
you
know
random
mistake,
or
we
didn't
think
through
here.
There's
a
reason
and
the
reason
is
everything
is
as
a
factory
method,
because
that's
the
powerful
api
and
then
things
that
are
fully
synchronous
are
constructed
parameters
fair
enough.
B
K
So,
by
the
way
I
I
have
to
run,
but
I
I
sent
you
guys
the
notepad
tags
that
I
was
typing-
okay,
I
honestly
so
I
don't
know
if
there's
an
appetite
for
adding
this
abstraction,
serialization
abstraction,
but
I
have
to
say
I
just
realized
during
this
meeting
that
it
solves
the
third-party
accessibility
problem.
Otherwise
I
mean
we
explored
many
paths
and
they
all
are
very
speculative
depend
on
some
compiler
features.
Don't
work
super
well
as
we
as
we
discovered.
K
No
serialization
technology
will
actually
want
to
add
dependency
on
binary
data,
probably
for
a
very
long
time.
So
I
I
think
the
abstraction
is
frankly
the
only
trackable
way
to
make
it
kind
of
out
of
band
extensible.
B
Right
the
the
problem
with
that
is
we
can't
we
can't
modify
the
existing
types
to
depend
on
a
new
base
class
in
a
way
that
works
for
net
standard.
So
it
would
have
to
be
we'd
have
to
come
up
with
what
the
abstraction
looks
like
and
then
put
sibling
types
that
are
just
wrappers
that
use
that
bridge
between
the
new
abstraction
and
the
existing
types,
because.
B
E
And
you
don't
want
to
expose
both
of
them
on
the
same
type
like
that
seems
now.
I
have
a
problem
of
like
okay,
which
which
thing
are
you
actually
meaning
like,
so
I
think
realistically,
almost
every
civilizer
will
end
up
with
whatever
types
they
currently
have,
plus
those
wrapper
types
right
right
and
I
think
that's
and
then
you
know,
given
it's
a
different
type,
you
can
choose
to
ship
them.
However,
you
want,
but
I
think.
B
Yeah,
and
so
I
think
that
as
building
the
stuff
and
building
all
the
sidecar
stuff,
I
think
that
there's
much
goodness
in
that,
but
I
don't
think
you'll
get
it
in
two
months.
E
Yeah,
I
think
the
object
still
has.
I
think,
given
that
this
one
seems
like
you
already
have
it
shipped.
We
know
what
the
api
shape
is.
I
can
probably
spec
that
out
relatively
quickly
and
we
can
convince
ourselves
that
that
is
trivial.
The
problem
is,
I
guess,
more
about
the
fact
you
know:
where
do
we
ship
the
actual
implementations
for
that
we
have
to
walk
through?
E
I
think
the
json
one
we
can
probably
ship
with
json
itself,
but
then
the
question
is
who
shifts
your
objectivizer
and
it
probably
would
have
to
be
a
separate
package
again
because
yeah,
you
don't
want
to
depend
on
json
in
order
to
get
the
abstraction
but,
like
I
don't
know
like
to
me
that
this
is
one
thing
that
I
think
is
very
tractable
to
me.
There's
still
this
bigger
issue
of
like
how
do
we?
K
K
Secondly,
if
we
think
that
actual
serializer
abstractions
would
I
mean
serializers
would
not
implement
the
abstraction,
but
rather
there
would
be
some.
You
know
other
package
that
kind
of
ties
them
together.
In
this
case
this
you
know,
serialized
abstraction
could
be
in
bind
with
the
same
package
like
the
binary
data.
E
Sure,
but
like
I
guess,
my
question
is
more
along
the
lines
of
so
let's
say
we
have
so,
let's
for
a
second
assume
the
object.
Sterilizer
is,
actually
you
know
a
closed
design
right,
so
so
assume
for
a
second.
We
already
shipped
that
design
right
or
you
know
it
doesn't
matter
where
it
ship,
but
that
assume
is
already
there.
E
K
K
K
K
B
Don't
have
that
one
yet
it
it
could
be
the
first
thing
that
actually
just
directly
implements
the
is
the
extension.
But
if
we
went
from
you
know
the
existing
system
text
json
or
we
were
doing
something
for
newton's
soft
json,
then
there
would
be
some
new
object
that
they
have
to.
B
B
B
The
moment
you
wanted
to
configure
it,
you
probably
wanted
to
save
it
to
a
field
somewhere
and
you're
just
referencing
the
field,
but
I
I
do
think
I
I
think
that
it
will
be
a
very,
very,
very
hard
sell
to
get
a
serialization
serialization,
abstract,
serialization
abstraction.
That
does
not
want
tea.
B
B
K
B
It
has
one
that
takes
object,
comma
type,
and
you
can.
K
B
B
E
K
F
F
E
K
K
K
B
I
think
that'll
be
the
hard
part
of
getting
that
discussion
through
is
figuring
out
what
the
abstraction
looks
like
to
figure
out
where
the
t's
come
in.
How
much
of
this
can
be
strongly
typed
so
that
you're
not
casting
away
from
object
again?
How
much
of
it
is
like?
Where
can
generic
inference
help
you?
Where
can
generic
return,
help
you
etc
so
that
you're
not
doing
back
to.net?
One
of
your
you
know
what
type
this
is,
but
you
have
to
write
the
cast
anyway,
because
there's
no
way
to
express
it
to
the
language.
E
I
think
to
the
question
then
becomes
like
I
mean
again.
We
have
shipped
this
recently
with
the
extension
methods
right
because
we
said
there
are
cases
where
you
just
don't
know.
The
type
statically
and
jan
was
ultimately
not
happy,
but
he
was
okay
with
the
design,
so
I
don't
think
it
will
be
a
ship
stopper,
but
I
think
the
question
now
becomes
if
we
do
have
that
here,
because
it
seems
like
your
design
only
has
object
and
type
right
versus
in
the
extension
methods
we
had.
E
We
had
both,
and
so
I'm
not
sure
how
much
of
this
is
a
problem,
then,
because
it
seems
like
with
this
design
effectively.
Nothing
is
linkable
because
you,
you
always
end
up
going
through
the
object
in
type
case
so
effectively.
Your
hello
world
scenario
using
binary
data
is
unlinkable
and
I
think
that's
a
bigger
problem.
K
So,
by
the
way,
so,
okay,
we
I
just
typed
the
constructor
that
is
untyped,
but
in
fact
binary
data
has
methods
of
t.
K
Like
two
because
binary
data
is
like,
I,
I
completely
acknowledge:
that's
not
a
general
purpose
utilization
scenario.
I
retrieve
some
payload,
I
kind
of
have
to
know
what
it
is.
Otherwise
I
would
I
was
more
commenting
on
the
serialization
abstraction
when
it's
just
a
general
purpose
serialization.
I
do
believe
it
needs
to
be
untyped.
You
literally,
I
mean
sure.
If
we
had
it
of
t,
people
would
do
what
I
think
eric
was
saying
which
is
just
type
object.
I
mean
past
objectivity.
B
Serialize
of
t
gives
you
a
lot
of
power
now.
Maybe
it
also
needs
the
type
or
the
object?
Comma
type,
I'm
just
saying
that's
where
the
the
design
and
how
do
they
flow
and
what
are
the
like.
Those
are
the
things
that
are
the
where
I
think
it'll
end
up
being
like
this,
where
we're
90
minutes
over
on
a
meeting
already.
K
E
So
then
action
item
for
me
is:
I
will
expand
the
spec
to
actually
include
the
shipping
vehicle.
I
will.
I
will
sketch
the
the
design
that
we
just
have,
which
seems
like
based
on
what
I
heard
is
we
leave
the
constructors.
We
have
the
statics
as
well,
and
then
we
say
like
eventually
we
will
have
a
still
as
abstraction
that
we
allow
people
to
pass
in
the
civilization
format
as
a
as
an
instance
of
object.
Serializer
is
that,
where
we're
landing?
E
F
B
Then
it's
obvious
that
it's
jason
and
you
don't
have
the
like.
Well,
don't
use
the
the
simplest
overload,
because
it's
not
the
format!
You
want
it's
well
that
one
says
it's
json
yeah.
K
So
I
would
basically
my
my
philosophy.
The
approach
here
would
be
today:
it's
json
once
people
learn
how
it
all
works,
and
you
know,
and
new
civilization
formats
become
popular,
there's,
just
a
parameter
that
you
control
it's
it's
fine,
because
all
because
basically
the
alternatives
are
impacting
usability
of
a
new
type
and
that
one
is
more
important
than
having
to
pass
an
enum
value
in
the
future.