►
From YouTube: .NET Design Review: JSON Serialization
Description
We'll review the new lean & mean JSON serialization/deserialization for .NET Core 3.0
https://github.com/dotnet/corefx/issues/34372
B
Okay,
I
started
working
on
this
in
December
part
of
the
initiative
to
have
an
alternative
to
Jason,
Evan
and
other
serializers
or
for
high
performance
and
leveraging
this
ban
so
Exedra.
Well,
we
want
to
get
this
in
three.
Oh
and
there's
a
huge,
a
number
of
features
that
you
know
people
ask
for
regarding
serializers
the
D
sterilizers.
So
the
idea
is
to
you
know,
do
a
minimum
version.
B
You
know
kind
of
test
the
waters
on
this
make
sure
it's
fast
make
sure
it's
designed
for
performance
first
and
supports
a
sink
and
use
high
level
design
goals,
and
then
you
know,
add
functionality
once
we
get
that
in
so
you
know,
there's
all
kinds
of
feature
requests
that
have
came
in
that
my
gathered,
some
and
put
them
in
you
know
like
a
to
do
section
or
pending
section,
but
in
general
I
want
to
try
to
keep
this
meeting
I'm.
Just
talking
about
the
api's
I
show
here
and
nod.
B
You
know
all
feature
asks
if
that
even
comes
up
it
might
not
so
other
constraints,
yeah
poco
objects
primarily
used
for
dto.
You
know:
data
transfer
scenarios.
This
basically
means
you
know
complex
inheritance
structures
and
having
references
between
objects
and
things
like
that
aren't
supported.
So
it's
basically,
you
have
your
object.
You
have
you
know
collections
and
those
can
contain
collection,
our
collections
or
primitives
or
other
objects,
etc.
In
a
composition
layer,
not
you
know
not
associations
to
other
objects,
and
things
like
that.
B
Okay,
API
is
designed
to
be
extensible.
So
what
this
means
is
that
partially,
because
of
you
know,
feature
asks
and
partially
because
we
don't
know
all
the
requirements
and
in
edge
cases
there
are
certain
plug
points
for,
like
you
know,
handling
enews
handling
dates
that
sort
of
thing
that
we
know
we
can't
ship
every
possible
way
to
serialize
and
deserialize
dates.
C
Questions
as
rich
one
is-
and
this
probably
I
briefly
looked
at
the
rest
of
the
document.
So
maybe
this
is
covered,
but
are
you
gonna
support
any
existing
attributes
or
just
create
new
ones,
and
then
the
second
question
is
at
some
point
either
now
or
later
in
a
later
release.
Will
you
support
build
time
koujun,
instead
of
just
run
time,
Co
Jen,
okay,.
B
You're
good
questions,
okay,
so
the
first
one
is
supporting
existing
attributes.
Yeah
the
system,
XML
namespace-
does
have
some
attributes
that
we
could.
You
know,
reuse.
The
problem
is
that
the
main
attribute
that
you
can,
for
example,
specify
property
name
like
if
you
want
to
change
a
property
name
also
has
like
five
other
properties
on
it.
That
don't
all
make
sense
here.
There's
other
interfaces
like
ID,
serialization,
callback
and
stuff
that
do,
however,
make
sense
once
we
get
to
that,
but
currently
I'm
not
reusing
any
any
attributes,
mainly
because
they
don't
fit
in
100%.
B
So
that
does
mean
that,
for
example,
if
you
have
a
class
that
you
know
uses
these
other
serializers,
you
know
you
may
have
to
add
another
attribute
or
something.
If
you
want
to
reduce
serializers
SP,
if
people
do
that
anyway,
I
don't
know
and
the
other
question
support
guilt,
I'm,
cold,
John,
yeah
I
mean
that
that
is
something
that
is
actually
probably
necessary.
If
you
ever
want
to
get
decent
per
fond
on.
You
know,
platforms
that
don't
support
IOM,
it
äôt
scenarios
and.
B
Dad
honestly
I
think
is
a
required
feature,
but
it's
just
a
scoping
decision
right
now
that
you
know
until
we
get
the
the
core
functionality
in
I'm,
using
Iowa
med
and
using
reflection
and
that
sort
of
thing,
and
actually
that
also
ties
in
with
extensibility
model,
which
I'll
talk
about
a
little
bit.
If
you
have
time
at
the
end
and
the
stability
to
say
hey,
you
know,
I
have
I,
have
50
classes
are
50
types
in
a
graph
here
and
I
want
to
serialize
them
and
49
work.
B
Fine
one
doesn't
you
know,
I
just
need
to
go
in,
and
you
know
hookup
is
weird
or
a
or
something
like
that
and
that
code
that
you
end
up,
writing
I
hope
in
the
end
it's
gonna
be
similar
to
are
the
same
as
what
we
have
for
build
time:
code
Jim.
So
when
I
get
to
the
extensibility
feature,
it'll
kind
of
tie
in
to
that
as
well,
that
you
know
that
the
API
is
and
the
mechanism
that
that
you
would
do
that,
hopefully,
would
be
the
same
as
what
we
generate
for
the
build
time.
C
C
A
One
way
I
could
see
this
being
done
this
similar
on
how
math
v2
worked
right.
Matthew
one
was
attribute
based
when
you
have
two
very
complicated
extensibility
model.
For
that
Matthew
two
was
more
around.
You
have
a
configuration
builder,
but
you
can't
effectively
configure
what
what
conventions
you
want
to
use
inside
and
you
can
chain
attributes.
You
can
train
a
naming
conventions
and
you
could
do
something
similar
here.
I
think
the
I
think
to
me
is
less
about
the
attributes,
because
the
problem
usually
of
civilization,
is
that
it's
not
just
the
attribute
right.
A
It's
the
kind
of
shape
that
instilled
as
I
can't
handle.
So,
for
example,
can
I
do
graphs,
or
can
it
only
do
trees?
Can
it
can
it
handle
read-only
properties
when
the
constructor
has
you
know
equally
named
arguments
right
in
and
those
are
not
necessarily
an
expression
of
attributes
right.
Those
are
you
know,
a
convention
between
the
civilizer
and
and
the
ties
you
can
serialize
but
I.
Think
that's.
A
Why
I
think
if
our
goal
is
to
bring
up
existing
libraries,
then
I
think
to
this
earlier
point:
I
think
it
would
be
it
and
non
so
trivial
undertaking
right.
If
you
look
at
Jason
the
net,
for
example,
it
will
handle
even
immutable
types,
but
it
will
even
handle
cases
where
you
have
completely.
We
do
only
you
know,
properties
and
only
constructors
affecting
our
codes,
and
it
will
go
out
of
its
way
to
discover
those.
The
following
is
that
all
these
things
are,
you
know
work
that
you
have
to
do
at
runtime,
potentially
as
well.
A
If
you
want
to
support
that
as
well
and
then
you
know,
you
basically
have
competing
requirements
now,
but
you
want
to
performance
or
whether
you
want
to
do
something
that
is
super
versatile,
I
think
the
goal
for
I
feel
as
it
here
is
more
towards
the
you
know,
design
your
types
to
our
API
service,
meaning
have
simple
focus,
and
then
we
will
work
just
fine,
but
if
you
try
to
retrofit
something
existing,
then
I
think
can
be
one
that
might
not
be
supported
at
all.
Yeah.
C
A
Yeah,
our
goal
would
only
be
performance
and
I
think
that's
probably
a
fair
statement
and
everybody
said
like
the
way
I
can
see.
This
being
done
is
with
a
configuration
or
convention
build.
Ever
you
can
register
what
conventions
you
have
and
then
we
were
activated
at
one
time
with
Revlimid
overdue
design,
time
code
spit
right,
I.
Think
the
the
problem
of
these
kind
of
things
is
more.
A
On
top
of
that
and
the
Parliament
that
approaches
that
you
know
you
you
it's
very
hard
for
us
to
not
break
them
in
the
future,
when
you
know
they
diversion
their
types
or
their
looping
in
one
of
our
types
and
a
movie
and
B
version,
our
type
right,
and
that's
one
of
the
reasons
why
I
think
the
the
only
guidelines
for
civilization
has
just
had
very
simple
types,
and
if
you
want
to
have
anything
more
fancy,
do
it
do
it
do
it
on
top,
so
it
civilization
becomes
easy
to
reason.
The
wrong
yeah.
C
Let
us
say
two
more
things
then
I'll
stop
one
is
I,
don't
think
we
can
reason
about
this
design
until
we
see
a
statement
that
says
X
percent.
We
expect
X
percentage
of
Jason
net
users
to
to
this
to
this
API
because
the
there
was
90%
it
has.
It
requires
a
certain
level
of
usability.
If
it's
10%,
then
it's
a
different
one
and
then
the
other
part
is
I'd.
Love
to
see.
C
There's
a
bunch
of
examples
in
this
document.
I'd
love
to
see
the
analogous
Jason
net
syntax.
For
that
exact
thing,
I
know
we're
not
trying
to
create
like
a
I.
Don't
think
migration
is
really
the
goal
here.
So
it's
not!
It's
not
like
the
code
has
to
look
the
same,
but
I
think
the
usability
of
one
code
sample
versus
another
is
super
germane
to
this.
E
F
I
want
to
echo
a
little
bit
of
what
rich
is
saying
there
from
the
asp
net
point
of
view
and
specifically
from
the
point
of
view
of
like
people
building
rest
api.
As
with
asp.net,
you
know.
Ultimately,
success
looks
like
to
us
some
high
percentage
of
users
that
are
happy
with
the
built
in
serializer
and
are
even
happier
with
the
built
in
serialize
because
of
better
performance
and
things
like
that.
So
it's
it's
kind
of
like
firmness.
F
For
that
point
of
view,
that's
almost
entirely
to
do
with
the
attributes
and
how
you
configure
serialize
or
different
settings,
and
things
like
that.
It
doesn't
be
serialized
things
in
the
way
that
you
respect
and
all
those
kind
of
details,
more
so
than
the
actual
in
the
eyes,
because
our
users
don't
interact
with
them.
That
often
now
I
can't
I
can't
necessarily
put
a
number
on
that.
We're
sort
of
invested
in
the
success
of
this
as
much
as
you
guys
are.
F
B
And
like
I
mentioned
early
on
here
that
you
know
okay,
I'm
right
now,
I'm
the
only
one
working
on
this
and
I've
been
starting
I
started
in
December,
and
you
know
when
you
talk
to
James
Newton,
you
know
it
took
them
or
you
know
12
years
of
12
releases
to
get
to
where
he
is
now
right
and
dozens
of
dozens
of
features,
and
we
don't
expect
anywhere
near
90%.
My
opinion.
Okay,
so
I
don't
know
what
the
percentage
is
gonna
be.
B
But
first
of
all
the
numbers
not
gonna
be
easy,
and
second,
we
never
stated,
and
we
don't
want
to
support
a
hundred
percent
of
the
features
you
know
there's
a
lot
of
overhead
associated
with
some
of
those
features,
so
I
don't
think
we
should
strive
for
90
or
100
percent,
necessarily
and
I.
Think
you're
kind
of
missing
the
point,
though
well.
C
B
C
C
C
A
I
think
I
think
to
your
point.
Oh,
like
I,
think
if
it
rephrase
this
thing
what's
the
percentage
of
customers
that
would
be
happy
with
the
both
and
Jason
civilization
I
think
that's
it.
It's
a
little
interesting
question
right
because,
as
Steve
said
like,
if
we,
if
we
really
want
to
replace
all
of
Jason's
or
net
usage
in
some
reasonable
time
frame,
but
even
if
that's
five
years,
that
effectively
means
you
have
to
subsume
100%
of
what
Jason
does
annette
has,
which
I
think
would
be
impossible,
as
we
literally
rebuild
it.
A
At
which
point
I
think
whatever
we
would
be
building
would
not
be
better
right.
It
would.
It
would
share
the
same
counter
and
Polly
would
be
worse
because
it's
something
new
but
I,
think
if
we
just
say
well,
assuming
you
know
you
know
new
net
new
customers
would
move
to
a
spinet
core
and
they
would
you
know,
ride
their
types.
A
You
know,
write
reasonable
apps,
a
reasonable
effort
and
even
though
they
have
what
they
have
to
do
is
different
from
Jason
that
so
long,
it's
still
easy,
and
it's
still,
you
know
a
pit
of
success
and
and
and
a
high
performance
and
I
think
that
would
be
okay
and
so
I.
Think.
From
that
point
of
view,
that
percentage
should
be
very
close
to
eighty
ninety
percent
right
I.
Think
if
we
go
here
for
forty
percent
or
thirty
percent,
then
we
basically
build
something
that
we
don't
think
is
good
for
our
customer
base.
B
C
C
B
Okay,
hon:
let's
move
on
prototype
yeah,
there
is
a
current
here's,
the
medical
okay.
There
is
a
prototype
in
corvex
lab.
It
has
on
the
implementation
of
90%
of
this
stuff
talked
about
in
here
say:
some
of
the
names
are
different.
For
example,
Jason
converter
options
is
called
yes
and
career
settings
anyway,
so
I
didn't
doesn't
necessarily
line
with
what
I
have
here,
but
it's
pretty
close,
okay,
so
the
API.
So
let's
just
start
at
the
very
top
and
rich
I
mean
I.
B
You
might
be
good,
I
mean
if
you're
not
familiar
with
Jason
Ned.
It
would
be
nice
maybe
to
have
an
intro.
If
that's
her
main,
you
know
target
the
way
we
want
to
approach.
Explain
the
api's
is
to
compare
and
contrast.
Could
you
know
every
serializer
seems
to
have
a
slightly
different
interface
for
the
very
front
and
I
took
approach
here
of
just
edit
class
button,
with
the
options
type
that
you
have
to
pass
in
so
I'm
scroll
down
a
little
bit,
so
it's
called
Jason
converter.
B
Objects
that
we
convert
to
and
from
and
one
is
a
span,
another
is
a
sequence,
other
one's
a
pipe
reader,
a
writer
and
then
a
stream,
and
then
a
string
and
the
spans.
The
sequence
are
based
off
of
bytes
and
so
is
the
pipe
pipe
reader
and
pipe
stream.
But
the
string
ones
are
a
little
special
that
we
kind
of
help
convert
from
utf-8
to
utf-16.
B
We
might
add
some
more
methods
here
for
utf-8
string,
but
meaning
api's
in
front
of
you.
I
could
walk
through
each
of
these
honest
I,
think
they're,
pretty
self-explanatory.
There's
generic
versions
and
then
there's
none
generic
versions
span
and
sequence
have
different
usage
scenario:
sequence.
You
know
you
can
have
multiple
byte,
arrays,
basically
and
they're
chained
together
span
is
the
new.
You
know
ref
struct,
that
for
performance
you
know
we
use
internally
quite
a
bit.
So
that's
the
preferred
API.
If
you
have
that
so.
D
Getting
an
object
that
you
peasant
know,
so
the
the
object
that
you
pass
in
is
the
object
that
you
want
to
be
serialized,
correct,
I'm,
looking
at
the
two
Jason
that
takes
all
trick
value
and
returns
a
span
of
height.
Yes,
that's
the
return
Jason
yeah,
but
what?
What
so
that
span
of
byte
has
to
be
backed
by
something
right.
D
I
D
Okay,
I
had
noted
that
right,
so,
as
one
example,
for
instance,
is
maybe
if,
if
you
had
a
an
overload
which
allowed
the
user
to
pass
in
an
array
pool,
then
maybe
you
could
return
the
byte
array
along
with
and
out
here's
the
length
of
the
data
that
I
wrote
to
the
byte
array.
That
way,
the
user,
like
the
caller,
can
be
fully
responsible
for
all
allocations.
So
you
can
still
have
an
allocation
free
API.
If
you
really
wanted
that.
A
Generally,
sorry,
I
don't
think
we
should
have
extension
methods
on
super
generic
types
like
it
fix
it.
For
example,
you
have
some
API
to
take.
Object
might
be
totally
don't
want
to
to
jason
extension
method
hanging
off
of
object,
but
also
didn't
make
them
extension
method,
but
I
think
the
same
can
be
said
for
stream,
or
we
the
only
sequence,
but
I
think
for
those
things,
you
really
want
static
methods.
Otherwise
it
will
be
a
bit
weird
if
you
have
these
super
generic
tides
that
have
fairly
specific
api's
on
them
now,
and
I.
B
A
I
I
And
then
for
the
from
the,
for
the
from
case,
I
mean
it
depends
on
what
you're
trying
to
support.
We
have
a
lot
of
api's
that
just
assume
that
the
the
span
you're
passing
in
either
represents
the
whole
piece
or
you're
not
going
to
be
trying
to
parse
what
comes
after,
whatever
you
ended
up
parsing
out
of
it.
So
you
don't
need
to
know
how
many
things
in
read
from.
B
I
So
it
depends
on
the
scenario
like,
for
example,
you
know
in
dot
parse
that
takes
a
read
only
span
of
char.
It
doesn't
tell
you
how
many
characters
and
read
from
the
input
span,
because
it
assumes
the
whole
thing
is
the
integer
and
contrast
utf-8
parser
takes
a
span
and
a
now
int
so
that
it
can,
because
it
didn't,
it
doesn't
assume
the
whole
input
is
the
thing
to
be
parsed.
So
it
tells
you
how
much
of
it
was
what.
H
B
That's
a
good
question
on
right
now
we
do
ignore
errors.
If
you
have
extra
data
at
the
end
of
your
whatever
you
pass
them
so
you're,
not
returning
me
out,
you
need
to
throw
yeah
and
Jason
that
has
a
flag.
You
can
specify
whether
you
want
to
throw
it
on
and
we
don't
have
that
plague,
but
throw
by
default
seems
probably
the
right
thing
to
do
so.
I
can
do
that,
but
that's
not
really
visible
in
API
right
now,
I
mean
no,
but
you
don't
know
whether
it's
going
to
throw
or
not
right.
H
B
I
I
Yeah
I
I
the
rules
are
more
complicated
than
that
and
in
this
case
I'm
not
sure
if
it
makes
sense,
so
the
only
value
to
she's
always
more
carefully.
The
only
benefit
to
using
a
value
task
in
this
situation
is
if
we
believed
that
to
Jason
a
sink
or
two
Jason
sink
where's
that
a
typo
I
guess
nobody
cares
yeah,
that's
a
typo.
If
we
believe
that
to
Jason
a
sink
would
be
able
to
return
a
value
task
that
wrapped
an
I
value
task
source.
I
So
if
to
Jason
a
sink
was
implementing
an
I
value
test,
source
interface
and
returning
a
value
test
that
wrapped
that,
rather
than
just
wrapping
the
value
task
around
a
task,
it
would
do
that
it.
For
example,
it
was
able
to
pool
the
I
value
task,
source
objects
and,
if
doing
so
yielded
a
you
know,
a
perf
benefit
from
not
having
to
allocate
that
additional,
say
70
by
object
for
each
call
to
to
Jason
a
sink.
I
My
guess
is:
there's
enough
other
allocation
happening
here
that
that
one
allocation
wouldn't
matter
and
it's
a
difficult
allocation
to
avoid
I
mean
today,
you
wouldn't
be
able
to
use
an
async
method
to
that.
To
implement
this.
This
it's
going
to
an
ASIC
method
is
going
to
have
an
allocation
either.
B
I
Going
to
complete
synchronously,
in
which
case
it
doesn't
matter
or
it's
gonna,
complete
asynchronously,
in
which
case
the
task
that
it
returns,
is
the
state
machine
that
was
box
to
the
heap
our
cocoa
box
to
the.
Even
so
you
already
had
that
allocation
anyway,
in
which
case
this
should
just
returned
tasks
rather
than
Melanie
tasks.
H
And
then
now
I'm,
like
so
I,
understand
the
the
object
returning
an
array
called
to
Jason,
but
the
ones
that
are
writing
to
a
to
writers.
I
feel
like
those
should
be
right,
Jason,
instead
of
to
Jason,
because
what
you're
the
purpose
of
the
method
is
the
side-effect?
That's
why
you
don't
have
a
return
type,
so
we
need
the
verb
to
indicate
what
the
side
effect
is.
H
D
I
will
act
as
a
foil
here,
because
at
our
last
API
review
we
actually
said
that
any
type
that
has
convert
or
converter
in
the
name
like
that
is
the
verb.
So
there's
no
need
to
put
an
additional
verb
on
the
method
names
and
you
mean
versus
leg.
You
mean
like
read
all
right
or
yeah,
because
we
have
an
actual
convert.
Clasp
yeah.
A
Honestly
I
was
just
more
laid
off
of
the
existing
tire,
which
is
better.
This
convert
class
with
the
steady
Cal
price
might
convert
to
in
32
I,
don't
Jason
converts,
you
do
Jason
seems
reasonable,
but
we
could
also
go
with
something
that
has
utilization
in
the
name
and
then
just
you
know,
nuke
the
namespaces
I.
Don't
think
it
will
have
that
many
types
in
the
names,
but
anyway.
H
H
A
B
Presumably
the
attribute
model
yeah
right
now,
there's
two
names:
sub
namespaces
right
now:
1
for
what
we
call
policies
and
then
one
for
converters
and
normally
normal
users,
don't
see
those
but
yeah.
All
of
the
other
attributes
that
you'd
want
a
place
on
your
type
would
be
in
the
same
namespace.
So
you
know
in
the
end,
maybe
a
dozen
you
know
home
to
two
dozen
at
the
max
I.
Think:
okay,.
B
A
A
You
know
walk
an
entire
object
graph
or
something
the
to-and-from
seems
a
bit
misleading,
because
it's
it
makes
the
operation
so
much
cheaper
than
they
actually
are,
but
I
think
for
anything
that
does
things
you
know
in
a
loop
or
something
you
would
expect
that
a
ride
or
a
read
method,
name,
I.
Think.
B
B
H
Serializer
that
read,
Jason
Jason
C
realize
are
not
right.
Jason,
those
those
things
like
natural
sentences,
jason
serialize,
are
from
jason.
When
you
already
have
contain
data
is
fine
or
it
could
be
right,
Jason
just
to
match
the
other
overland.
All
right
combination
with
you
so
the
to
and
from
I'm
fine
with
on
the
win.
It's
either
the
bytes
in
or
the
bytes
out,
the
one
where
it's
the
side
effect
nature
I
feel
that
the
read
verb
should
be
there
and
the
right
verb.
H
B
B
A
Yeah,
what
I
like
about
read
and
write
in
general
is
that
it
kind
of
is
consistent
with
the
rest
of
the
api's.
You
know
I've
in
the
in
the
in
the
JSON
namespace,
and
they
also
both
shortened.
So
if
we
have
to
support
other
shades,
like
you
know
the
JSON
string
example
or
the
async
ones,
then
we
sort
of
plenty
of
space
to
suffix
the
name
of
something
reasonable
without
creating
absord
API
names.
H
G
G
H
B
D
Yes,
okay,
I,
wanted
to
I
wanted
to
discuss
that
very
first
method,
real
fast,
the
one
that
takes
a
read,
only
Spano
bite
as
input.
That's
the
only
method
that
that
takes
a
ref
struct
as
input
and
I.
Wonder
if
that's
going
to
happen,
our
ability
to
generate
state
parameters
or
something
else.
If
we're
going
to
have
this
like
rich
attribute
model
for
controlling
serialization.
D
D
We
know
that
you
can't
you
can't
have
them
as
a
field
in
a
regular
struct
and
so
on
and
I
wonder
if
having
if
that
very
particular
API,
that
very
particular
one
that
takes
a
read
only
santa
bite
is
going
to
prohibit
us
from
introducing
AP
is
in
the
future
that
require
things
like
state
objects
for
controlling
how
various
properties
are
serialized
in
deserialized.
Imagine
something
like
like
data
annotations
like.
D
H
D
I
D
H
H
B
I
Async,
yes,
my
default
would
be
tasks
unless
you
can
prove
to
me
otherwise,
and
you
could
prove
to
me.
Otherwise,
if
you
could
tell
me
that
a
to
Jason
async
is
going
to
do
very
little
allocation
B,
it
would
do
it.
It
would
be
able
to
implement
I
value
tasks
source
as
a
backing
for
value
tasks
and
pool
it
appropriately,
so
that
which
is
how
you
would
avoid
any
allocation
associated
or
amortized
allocation
associated
with
these
calls.
I
The
side
can
I
just
interrupt
for
one
second
yeah
go
ahead.
The
the
more
interesting
question
for
me
would
be
that
from
Jason
async,
rather
than
the
to
Jason
hazing,
there
would
be
value
in
from
Jason
async
returning
values.
Ask
of
T
and
values.
Ask
of
object
more
value
if
we
believe
it
would
be
common
for
those
to
complete
synchronously,
because
if
they
complete
synchronously,
then
this
will
almost
certainly
allocate
a
task
where,
with
value
task
of
to
you,
wouldn't
be
necessary.
I
I
I
Yeah,
if
but
I
mean
it's
a
few
steps,
but
if
you
are
a
chunky
method,
you're
likely
to
complete
asynchronously
you're,
you
know
you're
gonna
be
using
async
methods
to
implement
it.
You
want
the
most
usability
default
to
returning
tasks,
tasks
of
T.
Like
that's
sort
of
the
default
choose
those.
Then
the
question
is:
when
would
you
potentially
switch
it's
a
little
bit
more
clear-cut
if
you're
returning
a
value?
So
if
you're
returning
a
T,
then
if
you
are
likely
to
complete
synchronously
and
if
allocation
is
important
to
you,
there's
a
good
chance.
I
You
want
to
return
a
value
task
of
teens
that
have
a
task
of
T
and
that's
because
when
you
complete
synchronously
with
the
task
of
T,
you're,
probably
going
to
allocate
and
with
a
value
task
of
T
you're,
probably
not
but
you're,
not
if
you're,
not
returning
it
to
you.
Basically,
if
you're
the
you
know
the
async
equivalent
of
void,
so
you
be
returning
tasks
or
value
tasks.
I
The
only
benefit
to
returning
value
task
over
tasks
is,
if
you
would
do
internally,
do
this
very
complicated
thing
using
I
value
tasks,
source
and
you
wouldn't
be
using
async
methods
to
have
lent
it
and
so
on.
So
we
do
that
in
a
few
specialized
cases.
You
know
we
do
that
in
in
socket,
read
async
write
a
sink
so
that
the
socket
can
cache
and
reuse
its
I
value
test
source
over
and
over
and
over
and
over
again.
We
do
that
in
pipelines
for
a
similar
reason.
We
do
that
in
channels
for
a
similar
reason.
I
I
B
F
F
D
At
that
case,
what
you
would
have
to
do
is
you
would
probably
want
to
either
rights
to
a
bike
stream
or
well.
You
would
probably
want
to
write
to
a
temporary
stream
or
to
a
string
and
then
transcode
to
whatever
encoding
the
actual
ones.
I
mean
you
could
wrap
it
with
it.
You
could
write
to
a
stream
that
is
a
transcoding
stream.
D
D
F
D
D
Honor
that
within
a
certain
range,
though
sure
and
I
guess
maybe
asking
for
steps,
wasn't
the
right
thing.
But
if
you
have
a
on
like,
if
your
gut
tells
you
that
this
isn't
going
to
be
very
common,
then
it
might
just
be
that
you
can
take
the
hit
of
doing
an
extra
transcoding
at
the
end
before
you
either
you're
right.
H
H
F
So
in
the
options
class
adds
another
sort
of
layer
to
it,
which
is:
do
we
have
a
perf
penalty
for
providing
you
a
different
options
class?
Every
time
we
call
you
a
different
instance:
do
we
have
to
build
a
caching
system
for
caching,
a
set
of
options
per
per
coding
users
also
like
to
mess
from,
from
my
point
of
view,
at
least
like
and
I'm
for
context?
F
Anybody
who
doesn't
know
me
I'm
talking
about
you,
know
web
frameworks,
asp
net
those
kind
of
scenarios,
users
like
to
mess
with
the
options
so
that
users
need
to
be
able
to
mess
with
the
options.
So
if
the
encoding
is
part
of
the
options
that
kind
of
crosses
a
stream
in
a
little
bit,
because
it's
got
stuff
that
the
user
cares
about
setting
up
mixed
with
per
request
information
that
has
to
be
dynamically
computed.
H
D
H
H
H
B
A
The
to
Ryan's
pointer,
like
I,
think
I
think
if
users
want
to
control
that
I
think
it
just
means
that
we
just
push
the
thing
out
to
a
higher
level
API.
Alright,
it
would
just
be
at
that
point.
Maybe
I
would
have
a
way
to
configure
that,
and
then
you
can
say
well
whatever
you
want
to
try
default
to
be,
and
whatever
you
want,
the
native
according
to
being
right.
It
just
wouldn't
go
on
that
time.
A
B
H
B
H
B
H
H
H
And
again,
the
workarounds
right
now,
based
on
the
fact
that
our
system
text
encoding
model
is
to
and
from
utf-16,
unless
we
wanted
to
do
double
encoding
on
everything.
The
easiest
work
around
for,
like
asp.net,
would
be
to
make
a
utf-16
there's
our
utf-8
to
whatever
encoding
stream
that
just
does
piecemeal
transcoding
into
the
underlying
stream.
B
B
D
So
the
what
we
did
in
MVC
model
binding
way
back
when
was
we
actually
have
a
lot
of
our
api's,
take
T
instead
of
just
object,
and
the
reason
for
that
is
if
your
model
inside
your
code
is
typed
as
T
model,
but
the
actual
object
that
you're
passing
in
is
a
derived
type.
You
probably
intended
to
serialize
just
the
model
properties
and
not
the
stuff
hanging
off
of
the
derive
type.
There
are
exceptions,
but
that's
the
decision
that
we
made
a
long
time
ago.
It
may
have
changed
since
then.
D
D
So,
in
that
back
when
I
was
working
on
full
frame,
work,
MVC
and
again
core
may
have
changed
this.
We
had
scenarios
where,
inside
your
method,
you
might
have
a
you-
might
have
your
model
typed
as
T
model.
Let's
just
say
your
models
type
this
person,
but
when
it
comes
back
from
your
database
it
might
be
derived
person
or
manager
or
something
like
that.
D
B
D
A
D
D
Wasn't
an
issue
feature
from
the
perspective
of
people
were
at
the
time
used
to
using
their
database
entity
models,
and
they
would
sometimes
have
properties
or
fields
that
were
only
relevant
to
the
database
layer
like
what
happens
if
the
type
is
internal,
for
instance,
and
there
are
public
properties
on
it,
are
you
going
to
serialize
those
or
not
yeah,
it's
down
to
the
cocoa
thing?
You
know.
D
F
I
can
confirm
that
we
do.
We
do
still
do
this,
but
agent
done
that.
The
place
where
this
is
really
important
in
practice
is
with
the
XML
sterilizers,
because
the
XML
sterilizers
care
a
bit
more,
but
with
with
JSON
dotnet,
we
do
pass
the
type
of
the
object
and
it's
based
on
the
return
type
of
the
method,
so
user.
The
point
is:
if
it,
the
existing
features
that
we
have,
the
user
does
have
control
over
specifying
what
type
it
should
be
serialized
as.
F
So
from
my
point
of
view,
we
can't
use
generics
because
we
can
never
write
the
type
name
of
some
user
gets
another
static,
our
point
of
view,
so
generics
I
think
the
generic
things
that
are
there
have
their
own
purpose,
but
I
specifically
asked
for
the
object
overloads
most
of
these
things
previously,
because
we
never
have
a
generic
type.
We
can
use
right,
yeah.
H
B
H
B
H
D
D
Sure-
and
some
of
us
too,
we'll
just
be,
will
just
be
considering
and
documenting
like
again,
what
happens
if
someone
passes
you
a
type
that
where
the
type
itself
is
marked
as
internal,
but
it
has
things
like
public
properties
like
are:
do
those
could
serialized
out?
Is
that
intentional?
Those
are
just
considerations
we'll
have
to
make
okay
I'm.
B
Just
gonna
keep
this
as
an
issue
and
I
guess:
I'll.
Take
it
offline
because
I,
don't
you
could
say
everything
any
feature
you
asked
is
security
feature
than
you
need
it
I
mean
that
doesn't
make
sense.
If
you
have
a
particular
feature
ass
that
needs
to
trim
the
inherent
as
hierarchy,
because
it's
a
security
issue.
B
D
B
Okay,
so
the
Jason
converter
options
class,
as
you
saw
above,
is
passed
in
optional,
Li
and
every
method.
Other
serializers
take
different
approaches.
For
example,
you
would
new
up
your
serializer
class,
which
would
have
the
methods
on
it
and
the
options
I
just
took
the
approach
here
of
passing
them
in
separately.
B
Part
of
the
design
revolves
around.
Hopefully
you
don't
have
to
pass
this
thing
in
and
have
to
cash
it,
and
you
know,
maybe
different
users
have
different
settings,
etc.
So
there's
a
lot
of
support
for
design-time
attributes
so
that
in
theory,
you
shouldn't
have
to
use
this
there's
some
environment
options
that
you
might
want
to
specify
like
max
depth
and
stacked
up,
and
things
like
that
that
you
know
you
wouldn't
want
to
put
in
an
attribute,
but
in
either
case
I.
B
B
Okay,
yeah
scroll
down
a
little
bit
more
there's
just
some
detail
here.
You
can
read
it
off
to
the
side
and
I'll
just
start
talking
about
some
API
is
okay,
so
this
very
the
constructor
I
added
a
way
to
disable
the
design-time
attributes.
I
did
get
some
feedback.
That
says
you
know
hey
how
expensive
is
that
yeah?
You
can
amortize
it
over.
B
You
know
this
is
called
whatever,
but
if
you
don't
want
the
extra
head
or
you
want
to
completely
override
all
of
the
design-time
attributes,
you
can,
you
know,
there's
option
to
do
that:
that's
what
the
disabled
design-time
attributes
parameters
or
on
the
clap
materializer
property.
This
was
optional.
B
You
know
situations
whether
the
current
environment
supports
reflection,
Amit,
it
gives
you
a
way
to
say:
hey,
I,
don't
want
to
use
reflection
Amit
because
it's
gonna
blow
up.
So
currently
that's
what
that's
for
in
theory,
that
could
go
away,
maybe
based
on
feedback,
maybe
based
upon
this
other
issue,
but
currently
it's
in
okay
default
buffer
size,
max
depth,
reader
options
and
writer,
okay
default
buffer
sizes
is
used
internally
to
help
us
create
the
initial
buffer
size.
B
By
default
is
minus
one,
which
indicates
we're
going
to
pick
a
size
which
is
currently
16
K.
You
can
set
it
to
whatever
value
you
want.
You
know
greater
than
zero
or
you
can
set
it
back
to
negative
one,
okay,
so
the
next
three
max
depth,
reader
and
writer
options.
These
basically
flow
down
to
the
Jason
reader
or
writer
and
I.
Have
a
review
note
here
that
you
know
we
could
explode
reader
options
and
writer
options
that
we
have
then
there's
drugs,
those
a
little
weird
to
have
get
two
sips
and
sets
on
them.
B
A
B
A
Yeah,
that's
why
that's
why
I
would
say:
I
wouldn't
slide,
I
wouldn't
flatten
them
out.
It
just
means
that
if
you
do
something
that
you
know
they
may
Eve
Adobe
dot
C
equals
blah.
You
just
get
a
compiler,
but
then
people
can
just
easily
create
a
local
variable.
Reader
options
set
it
to
whatever
they
want
and
then
just
assign
the
property
that's
better
than
us
having
to
like
duplicate
the
API
surface,
every
single
time
we
had
something
else
to
do
it
in
two
places.
I
agree.
B
Okay,
so
I'll
leave
that,
as
is
for
now,
I'm
gonna
skip
the
next
part
for
now
the
sirdar's
and
deserialize
and
case-insensitive
just
I'll
come
back
to
that
later.
So
the
add
attribute
methods
here,
as
I
mentioned,
that
you
can,
you
can
specify
design-time
attributes,
and
basically
this
allows
you
to
say
hey
if
I
can't
use
design-time
attributes
because
I
don't
know,
I
generate
the
type
at
runtime
they're,
not
my
types
or
whatever
reason:
I
have
to
change
the
values
at
runtime,
because
I
need
to
reuse
the
same
type
in
different
scenarios
anyway.
B
This
allows
you
to
basically
over
rise,
the
design-time
attributes
by
passing
in
an
attribute.
So
you
basically
new
up
an
attribute
and
I
say
hey.
It
belongs
to
this
type
and
that's
what
the
I
custom
attribute
provider
is
and
there's
also
an
overload
here
that
doesn't
take
the
type
you
know
and
just
a
deal
and
I
recently
added
this.
It's
been
feedbacks
that
this
would
be
a
global
setting.
That
is
not
ties
to
a
type
or
a
property
or
an
assembly
right
now,
cuz
I
custom
attribute
provider
can
be
an
assembly
and
there's
some
feedback.
B
B
A
A
I
mean
it's
not
very
well
known,
but
basically
your
scenario
here,
but
you
want
to
say
well,
I
would
like
reflection
to
pretend
that
this
particular
type,
or
this
particular
API
has
this
particular
set
of
attributes
is
something
that
we
actually
have
a
way
to
do
that
it's
the
whole
reflection
context
thing
that
you
can
say:
well,
even
the
sky,
pretend
that
this
method
or
this
property
has
these
attributes
or
that
this
type
has
this
attribute.
So
this
might
be.
B
All
right,
yeah
I
mean
you're
corrected
I'm,
trying
to
I'm
trying
to
do
one.
The
main
thing
I'm
trying
to
do
here
is
not
not
provide
with
look
at
classes
for
everything
you
know.
So,
if
you
have
an
attribute
that
allows
you
to
specify,
you
know
a
different
type
of
date,
time
converter
and
you're
familiar
with
that
attribute.
It's
like
well
now,
I
need
to
change
it
at
runtime.
I
know
what
the
I
know
what
the
design
time
attribute
is.
But
now
what
do
I
do?
At
runtime?
We.
B
A
Yes,
I'm
not
so,
as
I
said,
like
I,
don't
think
it's
that
unusual
I
mean
like
the
we
have
similar
errors.
Oh
we
did
this
in
the
past
right
where
there
was
math
or
I.
Think
some
of
the
data,
chronic
civilization,
had
similar
constraints.
Where
you
wanted
quent
you,
you
basically
want
to
serialize
something
or
you
want
to
discover
something,
and
then
your
problem
model
depends
on
the
presence
of
attributes
and
you.
A
We're
pulling
them
all
this
super
heavyweight
I.
Didn't
we
wouldn't
need
that
right,
I!
Think
if
you
want
to
do
that
here,
I
mean
we
should
look
into
a
reflection
context
and
the
reflection
context
is
this
thing
that
is,
that
might
be
overkill
for
what
you're
trying
to
achieve
here,
but
it
feels
like
that
might
be
what
we
want
to
do
here.
B
B
Something
simple
like
serialized,
Mel
values,
you
know
so
so
the
feedback
was,
you
know
it's
not
very
easy
because
there
is
a.
There
is
an
attribute
called
Jason
property
attribute.
You
can
put
on
the
type,
for
example,
to
say
serialize
you
know,
but
it's
not
very
discoverable,
so
these
got
lifted
up.
I
guess
you
can
say
to
here.
You
know
it
affects
performance,
a
tiny
bit
now
because
now
I
have
to
check.
You
know
basically,
two
places
at
runtime
figure
out
what
to
do.
B
But
this
is
one
approach,
at
least
for
those
properties
on
Jason
property
attribute.
There's
other
things
like
hey
I
want
to
register
a
new
converter.
You
know
right
now.
You
know,
you'd
have
to
use
that
ad
attribute.
I
didn't
like
try
to
lift
up
any
other
helper
methods
or
anything
like
that.
But
for
now
I
did
put
these
three
properties,
which
are
the
only
three
properties
currently
adjacent
property,
attribute
that
we'll
get
to
in
a
little
bit.
But
there's
probably
going
to
be
ten
to
twenty
here.
A
I
have
one
question
like
if
you
look
at
like
the
hello
world
sample
code?
Is
the
expectation
that
a
hello
world
you
know
poco
that
I
have
to
serialize
or
D
Co
lies
I
have
to
put
at
least
one
attribute
somewhere
or
can
you
just
have
a
the
plain
poke
with
no
attributes
and
you
are
able
to
handle
that
yeah.
B
B
A
B
Right,
D,
the
alternative,
let's
say:
I,
don't
have
these
properties
here
these
three
properties,
because
there
is
this
attribute
called
Jason
property-
attribute
that
if
you
don't
want
to
put
it
on
your
PO
code
type,
that's
fine.
You
would
have
to
pass
that
in
at
runtime
to
add,
attribute
and
I
guess
that
that
was
the
you
know,
this
discoverability
I
guess
for
these
common
properties.
I
see
her
up,
you
might
want,
so
you
can
still
call
it
out
attribute
pass
in
the
class.
B
A
B
I
think
90%
of
time.
Global
is
fine,
it's
just
if
you're
using
other
people's
types,
maybe
or
maybe
for
multiple
people,
that
you
know
things
get
a
little
goofy
and
you
and
or
if
you
try
to
share
the
same
options
class,
for
example,
because
the
options
class
an
instance
of
it
will
contain.
You
know
this
state
on
it
as
well
as
any
attributes.
You
added.
So
if
you
try
to
use
that
same
instance
of
the
options
class
with
with
other
random
type,
Foucault's
types
that
you
have
and
they
have
different
semantics,
then
yeah.
B
I
would
say
that
the
case-insensitive
property
name
is
probably
going
to
be
something
that
asp
net
is
gonna
set
to
true
and
also,
although
it's
not
shown
on
here,
there's
a
camel
casing
play
that
are
attribute,
camel
cases
handle
and
a
little
different
than
just
a
simple
bool
or
here
so
so
there
are
a
couple
options.
I
think
that
that
we
optimize
kind
of
for
Jason
syntax,
our
schema
like
okay.
First,
first
of
all,
you
don't
probably
have
case-insensitive
property
names
by
default
because
number
one
Jason
is
case,
sensitive
and
number
two.
B
It
takes
a
little
bit
more
time
to
do
that,
so
we
default
to
false
camel
casing
same
thing.
By
default,
you
know
we
we
will
do
use
whatever
value
you
have,
which
is
normally
pascal
case,
but
it's
pretty
common
that
you
want
to
Jason
to
be
Kalyan
cased.
So
there
are
a
couple
options.
I
think
that
half
of
the
users
will
probably
want
to
set.
B
B
Jason
as
a
schema
or
as
you
know,
standard
doesn't
care,
I
mean
it.
You
can
do
whatever
you
want
right.
I
mean
it's
regarding
the
input
coming
in
and
mapping
it
to
your
object,
but
Jason
net
does
his
case-insensitive
by
default.
So
this
would
be
true
by
default.
I'm
proposing
that
it
be
false,
let's
see
or
like
I
said
performance
and
because
Jason
standard
is
his
cases,
but
that's
open
for
discussion.
Like
I
said
it's
the
first
API
review
and
I
didn't
why.
B
If
they're
not
set,
then
then,
if
they're
set
some
other
way
through
design-time
attributes,
then
that
will
get
picked
just
picked
up.
Instead,
it
matches
the
adjacent
property
attribute.
If
you
look
on
there,
they
can
they're,
also
knowable,
and
it's
like
hey.
If
it's
nullable,
then
we
there's
a
default
unless
it's
over
it
and
that's
some
other
some
other
way.
A
B
In
this
case,
because
it's
on
these
options-
class,
yes
and
in
actually
I,
had
that's
a
good
point.
I
need
to
write
up
a
description
on
that
override
because
attributes
can
be
overridden
like
a
prawn
attribute
on
her
property
would
override
the
same
attribute
on
a
class,
but
how
it
applies
that,
to
this
instance
of
this
options
class
it.
B
Story
here,
you're
right,
you're
right
in
that,
in
that
case,
I
was
I,
was
thinking
of
right,
no
you're
you're
right
like
an
ID
and
I,
do
talk
about
that
later
on,
but
I
don't
talk
about
it
applying
to
this
options,
but
yes
I.
This
would
only
like
I
said
earlier.
That
is
knowable
because
unless,
unless
it's
overridden
at
a
lower
level,
you're
gonna,
if
I
said
any
here,
it
defaults.
If
is
not
a
reader
yeah.
A
A
B
What
I,
what
I,
what
I
was
thinking
of
when
I
said
that
was
that
the
add
attributes
method
here,
the
runtime
versions
will
override
the
design
times
versions
if
everything
is
equal.
So
if
you
have
an
attribute
that
says
serialize
null
values,
a
design
time,
you
know
false,
and
then
you
change
it
to
true
at
runtime.
The
runtime
value
is
used
instead
of
the
design
time
tell
you.
B
A
B
A
B
B
B
If
we
want
to
keep
them
here
and
that's
I
guess
why
I
have
this
design
note,
is
that
they're
here
for
a
usability,
but
in
theory,
there's
an
alternate
mechanism
throughout
attribute
that
you
can
specify
these,
but
I
think
you
know
I've
lifted
them
up
based
upon
feedback
which
I
agree
with
that?
It's
just
confusing
to
you
know
the
this,
for
the
simple
case
is
not
to
have
these
easily
accessible.
G
G
B
B
B
B
Only
override,
if
they're
null
you
mean
none
that
if
they,
if
the
properties
on
jason
property
attributes
are
are
null,
then
they
will
override
don't
over
read
they
provide
no
I
mean
they
will
provide
the
default.
I.
Guess
there's
a
default.
You
know,
if
you
don't
specify
anything
so
I
didn't
do
xml
doc.
Yet,
but.
H
B
B
H
B
G
G
H
So
just
wondering
what
the
what
the
same
default
would
be
for
the
the
deserialized
version,
because
I,
if
I,
have
a
class
that
instantiated
a
property,
but
the
Jason
explicitly
had
the
words
null
in
it.
I
would
expect
that
property
to
be
null
so
I
would
think
that
that
one
would
be
default
to
yes
and
then
the
whether
or
not
null
should
be
written
out.
I
would
think
that
the
current
industry
pattern
would
be
to
default
and
not
writing
the
null
I.
M
B
L
So
Jason
dotnet
defaults,
both
of
those
are
true,
and
there
is
a
difference
semantically
in
JavaScript,
between
a
property
missing
and
a
property
being
null.
So
whether
this
is
true
or
false
has
has
an
effect,
and
in
JavaScript
like
if
someone
is
expecting
middle
name,
to
come
back
as
null
and
instead
is
completely
missing.
That
could
affect
how
their
program
runs
versus
a
like
an
empty
string.
You
mean,
or
no
no
versus
the
the
property
being
completely
missing.
L
H
B
You
yeah,
okay,
I,
took
the
performance
on
default
here,
which
is
I.
Guess
if
you
don't
serialize
the
null
values,
you
probably
won't
deserialize
I'm
number
one.
You
know
if
you're,
if
you're
doing
both
and
then
of
course,
decrease
your
payload.
If
you
have
bloated
nulls
and
then
on
the
same
for
the
DC
realizes,
you
know
why
I
said
it.
If
you
don't
have
to
normally
values
are
going
to
be
known.
Give
me
a
new
object.
B
And
I
guess
this
does
open
up
an
interesting
design
point.
Is
you
know
regarding
compatibility
or
even
interrupts
with
Jason
Ned?
Regarding
you
know
semantics
here
in
deep
balls,
you
know:
how
do
we
want
to
align
I
mean
I.
You
know.
Part
of
the
goal
here
is
to
be
fast.
That
doesn't
mean
you
have
to
I
have
to
set
every
single
property
of
you.
You
know
the
fastest
is
default
because
you
can
change
some
of
those.
B
L
I
think
I
think
that's
fine,
like
I've,
had
feedback
worth
chasing
on
it
that
people
have
wanted
it
to
be
case,
sensitive
and
I.
Think
at
some
point,
I'll
add
that
as
a
feature
to
have
this
flag,
but
obviously
the
the
default
would
be
the
reverse,
but
I
think
there
I
think
Jason
Don
it's
unusual
and
that
it
does
case
and
sensitive
property
deserialization
like
everything
else
like
data
contracts,
your
Eliza
as
as
case
sensitive,
so
I,
think
and
in
that
case
Jason
on
it's
the
odd
way
out
odd,
odd
man
out.
H
For
there's
no
money
for
no
value,
I
think
that
we
should
go
with
the
principle
of
least
surprise,
which
is
why
I
think
that
deserialize
should,
if
deserialize
sees
a
null
your
resultant.
Hydrated
object
should
have
null,
even
if
it
had
a
default
value
in
a
constructor
and
serialize.
No
I
don't
have
a
strong
opinion
about.
But
if
you,
if
you
think
they
should
match,
then
that
means
they
should
both
be
true
by
default.
And
if
you
want
to
reduce
your
payload
type,
just
go
to
false
particulars
null.
So.
D
D
So
in
I,
guess
you
you
still?
You
still
need
the
ability
for
someone
to
specify
that
right.
So
the
the
scenario
is
I'm
patching
a
model
on
my
web
server
and
I
really
really
really
do
want
you
to
overwrite
these
very
particular
properties
with
null
but
I
that
yeah
I.
That
is
an
uncommon
case.
Yeah
I'll
admit
that.
A
If
you
actually
have
a
domain
object,
where
you
have
a
constructive
or
some
policy.
Well,
then,
maybe
you
want
to
turn
it
on
and
say.
Well,
if
the
caller
went
to
the
trouble
of
passing
me
nah,
then
maybe
I
should
set
it,
but
I
think
the
question
is
like
what
is
a
reasonable
default
right
and
I.
Think
for
serializing,
it's
probably
going
to
be
false,
will
be
my
guess
and
for
this
realization,
I
think
it's
probably
also
for
Papa's.
At
least
you
know
ignore
effectively.
H
And
I'm
just
trying
to
think
of
the
stack
overflow
question:
why,
when
I
read
this
thing
and
I
wrote
no
in
the
Jason,
is
it
not
null
coming
out
of
the
serializer
by
default
and
that
the
again
that
so
I'm
just
started
doing
least
surprise
and
the
end?
Then
consistency
with
us?
You
realize
there's
consistency
with
the
browser's.
It
sounds
like
they
should
both
be
true
by
default,
and
if
you
want
to
account.
L
G
B
B
B
Maybe
you
know
aligns
better
with
other
areas.
Well,
on
that
sir
dies
that
you
serialize
and
all
so
I
guess
it
goes
back
and
yet
the
options
there
is
it's?
Ok.
What
do
we
expect
by
default?
You
know
and
I.
Actually,
you
know
III
see
both
ways,
I'm
kind
of
leaning
towards
changing
this
to
serialize
and
deserialize
by
default.
True
and
then
case,
you
know,
keep
it
case
sensitive
just
to
align
better
in
other
areas
and
then,
of
course,
we
do
take
a
perf
hit.
G
I
mean
that
sounds
good
to
me.
My
only
point
was:
it
was
a
pair
of
failure,
because
people
Mike's
the
comments
case
could
be
I.
Don't
care
were
no
values
and
now
you're
forcing
me
to
accept
this
flag.
Even
if
they're
not
were
performance
about
there,
I
did
ignore
they
don't
want
no
values.
If
so,
that's
the
question
because
they
what's
the
common
scenario:
do
people
want
know
that
is
in
their
output
or
they
don't
yeah.
B
Honestly,
I
might
my
opinion
is
paralyzed.
Null
values
should
probably
be
false,
I
mean
that's.
What
I
would
expect
as
a
developer
and
deserialize
should
probably
be
true.
You
know
like
I
said
before.
If
you
see
really,
if
you
don't
see,
realize
null
values
well,
you're
not
gonna,
come
back
again,
at
least
if
you
control
your
own
data,
you
know
so
I
I
think
that's
fine,
but
setting
to
both
the
true
might
be
the
safer
thing.
It's
not
gonna
be,
but
you
thought
the
most
performant
thing
that
yeah.
A
I
think
the
interesting
thing,
though,
is
I
was
originally
thinking
the
same
way
but
like
as
in
serializing
should
be
false,
and
this
resin
should
be
true.
The
the
only
thing
that
is
odd
is
that
the
only
reason
why
you
would
care
in
that
case
is
because
you
have
a
constructor
that
applies
pilled,
but
that
applies
some
meaningful
policy
and,
if
that's
the
case,
I
think
you
generally
want
to
serialize
not
abilities
because
they
deviate
from
what
the
default
state
is.
In
other
words,
they
become,
but
Louisa,
that's
our
first.
Do
we
support
contractors?
B
A
What
I'm
trying
to
get
this,
that
even
odds,
are
meaningful
of
they're?
Not
so,
in
that
case,
you
should
either
make
them
both
these
basically
I
think
whatever
default.
We
do
that
should
either
they
should
both
be
the
same
as
soon
as
you
deviate,
I
think,
you're
you're,
creating
is
somewhat
of
an
odd
world.
A
A
few
much
long,
I
think
honestly,
my
my
gut
feels
that
would
make
them
both
balls
by
default.
Given
our
scenario
because
I
think,
probably,
if,
depending
on
how
we
go
with
this,
but
if
you
really
push
people
down
towards
the
polka
model,
then
I
think
there's
no
harm
in
making
them
false
and
it's
generally
better
for
payload
size.
But
if
we
feel
like
okay,
people
will
do
constructors
with
meaningful
things,
then
I
would
say
make
them
both
to
work
well,
I
just
think
making
them.
H
Yeah,
like
it,
my
feeling
is
just
yeah,
but
all
the
James
is
consistency
arguments
and
then,
if
somebody
does
do
a
a
they
initialize,
a
value
with
a
field
initializer
just
that
again
the
questions
that
people
would
have
when
they
get
confused
of
I
wrote,
know
in
the
payload
or
rather
I,
seen
all
in
the
payload.
Why
is
my
value?
Not
null
that
question
to
me?
H
Just
feels
ridiculous
and
I
think
that
we
should
go
for
it
said
null
d
null
is
the
default
and
it
said
no
I'm
not
gonna
call
a
setter
is
a
perfect
roodman
and
then
once
we've
chosen
that
one,
then
the
consistency
with
read
and
write
says
they
should
both
be
true
in
case
insensitive
should
be
fault.
I.
K
H
So
the
the
limit
is,
if
somebody
in
a
field
initializer
sets
a
value,
then
the
jason
says
null.
They
would
be
confused
why
their
value
still
have
the
default
instead
of
being
null
yes
and
so
I
think
we
should
avoid
the
confusing
state
by
default
that
happens,
to
match
the
consistency
with
our
other
serializers
and
with
what
the
browser
does
with
string
up
or
with
the
JSON
type
and
then
by
the
read
and
write
should
have
parity
argument
that
you
had.
That
means
that
serialize
null
value
should
also
be
true.
Okay,.
B
H
B
I
didn't
clarify
that
before.
No,
if
you
say,
recommend,
there's
there's
two
things
that
can
happen.
I
guess
one
is.
If
we,
if
different
quarto
Japan
the
platform
you're
on
yeah,
it
will
throw
us
a
you
know,
not
supported
right
away
literal
and
then
then
the
other
thing
is
well
we'll
give
it
a
try
and
then
you
make
it
a
random
exception
which
happens
today,
which
case
is
like
a
new
WP
that
it
kind
of
works
depending
on
what
you're
trying
to
do
and
I
don't
know
if
it
work
with
this
particular
just.
G
To
back
up
just
a
bit
for
max
depth,
it
seems,
like
you,
have
one
back
step,
but
the
reader
rather
had
different
match
step.
Maximum
has
semantics.
There's
two
questions
here.
One
is:
should
we
have
read
a
specific
masters
and
register
a
man's
that
one
second,
should
we
change
the
video
options
right
officers
to
incorporate
back
step
so
that
you
rapid,
saw
the
seer
as
a
level
yeah.
B
B
B
H
G
H
B
L
I've
got
a
question
about
where
you
cash,
like,
I
assume
the
first
time
you
serialize
a
type
you
build
up
a
contract
of
it,
so
you
reflect
over
top
of
it
and
then
you
cash
that
reflection
somewhere.
Is
that
case
against
the
options
or
as
a
cashed
in
a
central
place?
Well,
the
reason
I
ask
that,
is
you
have
these
ad
attribute
methods
on
options?
B
B
Yeah
so
originally
I
didn't
have
these
other
on
properties.
These
three
properties
for
null
vely
handling
and-
and
things
like
that
now,
since
I
added
them
here,
which
are
not
reflected
in
my
prototype,
I,
have
to
reconsider
that,
and
it
may
be
that
you
know
if
you
said
any
of
these
properties
or
call
any
of
the
add
attribute
methods,
then
the
cache
will
have
to
be
associated
with
the
instance,
and
you
know
not
sure,
globally,
right.
L
Okay,
with
let's
chase
and
on
it
like
a
lot
of
those
flags
like
no
value
handling,
that's
handled
at
runtime,
it's
not
baked
into
any
generated
il
or
anything,
and
it's
really
the
the
contracts
stuff
is
sort
of
constrained.
So
the
the
is
a
data
contract,
resolver
I,
think
with
unchastened
on
that
and
that's
the
thing
which
has
all
the
caching
in
it.
So
that
allows
people
to
new
up
jason
serializer
settings
and
set
those
flags
and
not
worry
about
it.
L
Well,
if
you're
going
to
be
baking
in
these
settings,
and
so
the
cache
which
is
might
include
generated,
al
people
would
need
to
be
really
careful
about
caching
convert
options
because
I
can
imagine
people
just
mooing
up
the
converter
options
each
time
they
want
to
call
serial
serialize
and
they
set
serialize
null
values
to
false
because
they
want
to
keep
their
payload
size
small.
But
what
we're
doing
is
they're
recomputing
all
this
reflection
and
IO
generation.
Every
single
serialization
yeah.
B
And
that's
a
good
point.
I
do
think
in
particular
those
three
values
and
they're
probably
more
later,
but
it's
possible.
You
know,
I
can
check
the
cache
the
value
and
then
compared
this
and
avoid
having
to
you
know
cash
in
those
simple
scenarios,
but
currently
the
cord
in
the
prototype
does
detect
the
call
to
add,
attribute
and
kind
of
flip
up
flip
a
switch
stored,
locally
mm-hmm
I
have
to
I
have
to
think
about
that
and
whether
yeah
I
want
to
check
into
places
I
guess
to
avoid
catching
for
simple
scenarios.
B
A
I
think
there's
more
stuff
we
need
to
go
through
it
I
mean
that
you
should
definitely
talk
about
the
attributes
and
the
program
model
that
me
maybe
will
be
use
on
top
I.
Think
that
you
I
think
we
got
a
decent
amount
of
feedback
for
you.
I
don't
know
like
do
you
want
to
take
another
iteration
to
two
with
them?
Your
proposal
based
on
that
or
do
you
want
to
rather
finish
it
and
then
oh.
B
Definitely
I
want
to
update.
You
know
that
the
core
API
section,
so
we
can
revisit
that
and
then
you
know
hopefully
that'll
be
quicker
next
time
and
then
we
can.
We
can
hit
some
of
this
other
stuff
and
and
this
and
I
do
not
have
some
everything
in
here.
There's
like
I,
said,
there's
pending
features
and
I'm,
not
sure
exactly
what's
gonna
fit
in
three
open,
but
this
right,
what's
in
here
right
now,
is
like
the
Minimum
Viable
Product
for
X
percent
of
people
right
all.
A
A
You
very
slow
did
you
drop
off
I?
Guess
he
dropped
off
yeah.
So
then
let
me
just
set
up
another
meeting.
I
guess
next
week
will
probably
be
a
good
time
and
then,
unless
there's
something
scheduled
but
I,
don't
think
there
is
and
then
we
can
take
it
from
there.
Okay,
thank
you
thanks.
Everyone
awesome
thanks,
guys
online
and
stay
saving
the
snow.