►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
All
right,
good
morning,
good
day,
everybody
today
we
are
focusing
our
attention
on
the
object
still
as
abstraction
that
we
had
in
the
books
for
a
while.
Finally,
the
right
people
are
back
from
vacations
or
random
things.
They
have
been
doing.
A
And
I
think
this
abstraction
came
to
be
because
the
first
version
of
the
of
the
azure
sdk
predominantly
used
newton's
of
json
and
then
when
they
wanted
to
add
support
for
system
text.json.
They
didn't
want
to.
Basically
you
know,
duplicate
the
api
surface
instead
have
an
abstraction
that
allows
you
to
basically
just
say
yep.
Here
you
go
something
that
you
know
yeah.
A
We
may
want
to
serialize
later,
like
cosmos
db,
where
you
basically
put
in
your
own
objects
and
then
they
sealed
as
the
objects
on
your
behalf
as
they're
manufacturing
the
message
that
gets
sent
back
to
the
server
and
I
feel
like
when
I
wrote
it
up.
I
pretty
much
just
copied
the
api
shape
that
I
think
they
had
and
I
think
the
only
changes
I
made
was
the
namespace
and,
as
it's
hopefully
apparent,
this
is
not
a
proposal.
Yet
it's
just.
A
You
know
the
idea
that
if
we
were
to
put
it,
it
would
be
somewhere
in
system.
Is
there
anything
that
I
didn't
cover
christoph?
Is
that
kind
of
setting
its
own.
B
One
additional
kind
of
maybe
note
about
motivation:
it's
not
only
that
we
don't
want.
We
kind
of
want
people
to
be
able
to.
You
know
pick
with
serializer.
It's
also
for
people
who
want
to
transition
from
existing
libraries
that
used
newtonsoft
and
because
our
new
azure
sdk
libraries
ship
with
the
system
tex
json
serializers,
but
some
customers
already
have
data
types
that
are
serialized
using
newtonsoft
and
suddenly
they
they
get
the
azure
sdk
library
they
try
to
serialize.
B
And
there
are,
you
know
very
sad,
behavioral
differences
in
how
how
the
data
types
are
serialized,
so
for
them
to
transition
to
new
azure,
sdk
libraries.
They
have
to
get
back
to
the
original
semantics
and
therefore
this
abstraction
basically
allows
them
to
say.
Well,
I
I
got
the
azure
sdk
library.
I
try
to
serialize,
I
like
the
library,
but
I
try
to
serialize
my
data
types
and
there
are
some
differences.
I
want
to
snap
back
to
the
old
behavior,
so
they
basically
can
use
this
api
to
plug
in
newton's
off.
B
So
it's
more
like
a
it's
a
transition
feature,
and
I
I
thought
it's
interesting
to
to
kind
of
add
this
node,
because
I
assume
many
customers
who
transition
from
newtonsoft
to
system.json
would
appreciate
if
libraries
let
them
basically
were
using
this
abstraction
and
we're
allowing
them
to
to
change
the
serialization
behavior
through
it.
B
A
B
A
B
D
B
Maybe
maybe
this
will
work
better?
No,
that
doesn't
work
better
anyway,.
A
And
to
be
clear,
this
abstraction
is
not
meant
to
just
abstract
json
right.
It's
it's
meant
to
abstract
any
serializer
right,
so
it
could.
You
know
in
principle,
be
used
with
binary,
formatter
or
protobuf
or
whatever
serializer.
It
is
right.
It's
just
here.
Are
some
bytes
give
me
an
object
or
here's
an
object.
Give
me
some
bytes
right.
That's
effectively
the
contract
of
it.
E
E
Well,
protobuf
is
a
kind
of
index
based
field.
Serializer
it's
going
to
require
more
information
than
is
just
in
the
token
stream.
It's
not
good
enough
to
hand
it
an
object
and
say
serialize.
You
have
to
have
the
actual
like
protobuf
file.
That
shows
the
tags.
B
A
B
Yeah,
because
there
is
always
for
concrete
serializers,
there
will
always
be
some
information
that
is
specific
to
the
implementation
of
the
serializer.
So,
for
example,
for
json
there
are
all
the
json
options
or
settings,
and
you
provide
them
during
construction
and
same
with
protobuf.
You
would
provide
them
during
construction.
F
I
think
it's
a
property
of
I
mean
any
serializer
is
going
to
have
limitations
on
what
types
it
can
serialize.
It
might
be
implicit
to
the
nature
of
the
serializer.
It
might
be
implicit
to
how
it
was
constructed.
There's
only
a
finite
set
of
types
that
you
can
serialize
with
json
serializer,
for
example,
there's
only
a
finite
set
of
types
you
can
serialize
with
binary
formatter
for
that
matter,
right
things
that
have
been
attributed
appropriately.
I
think
the
difference
in
this
case
is
it's:
it's
not
inherent
to
the
sterilization
mechanism.
A
If
you
would,
let's
say,
say,
cosmos
db,
you
want
to
say,
store
document
retrieve
document
you
want
to
pass
in
your
actual
instance
of
the
document
you
don't
want
to
have
every
single
call
site
have
to
deal
with
serialization
right,
but
now,
in
order
for
that
to
work,
you
kind
of
need
to
let
cosmos
db.
Now,
okay,
how
would
you
like
to
serialize
this
thing
right?
What
sealant
do
you
want
me
to
use
and
that's
basically,
what
this
thing
would
do
right
it
would?
A
It
would
still
mean
that
yeah
if
the
user
wants
to
use-
let's
say
newtons
of
json,
and
they
want
to
customize.
Let's
say
how
you
know:
properties
are
represented
in
json.
Well,
they
would
have
to
use
the
newtons
of
json
attributes
for
that
right
and,
if
they
use
hours
well
then
that
won't
work
if
they
pass
in
the
newton
soft
object,
serializer
instance
to
the
cosmos
db
api
right.
So
it's
still
yeah.
A
A
B
But
I
think
it's
useful
to
kind
of
talk
and
look
at
real
scenarios
like
how
it
works
in
libraries.
So
again,
going
back
to
my
example
of
transitioning,
let's,
let's
say
cosmos
from
newton's
soft
to
system
text,
json,
basically,
cosmos
clients
would
have
a
property
that
is
object.
Serializer
type,
I'm
hand
waving
the
details,
but
imagine
that
on
cosmos
client
there
is
a
property
called
serializer
and
the
type
of
this
property
is
object.
B
Serializer
by
default,
the
property
points
to
system
text,
json
implementation
of
the
serializer
and
that's
how
most
of
our
customers
use
the
cosmos
library
and
they
are
happy
with
it
from
time
to
time.
There
is
a
customer
who
wants
to
serialize
types
that
they
use
to
attribute
from
newtonsoft
and
now
with
the
cosmos
library
doesn't
work
for
them.
B
B
F
Can
I
try
and
parent
that
back
to
you
kristoff,
to
make
sure
I
understand
the
scenario.
I
think
what
you're
saying
is
I,
as
the
the
user
of
a
particular
library,
there's
a
library
that
accepts
a
serializer
and
it
accepts
instances
of
types
from
me
and
it
will
only
ever
try
to
serialize
my
types
with
the
serializer
that
I
have
provided
to
it.
A
It's
also
worthwhile
saying
that's
kind
of
how
asp.net
works
today
and
interesting
thing
for
asp.net.
Is
there
really
isn't
an
api
for
a
customer
to
conveniently
say
which
steelizer
to
use
right?
Because
if
you
write,
for
example,
the
web
api
style
api,
where
you
have
a
post
method
right,
it's
all
based
on
conventions
right,
your
method
ends
in
post.
You
return
and
you
know
an
instance
of
some
type.
A
Let's
say
I
innumerable
of
customer
and
then
the
framework
is
basically
on
the
hook
for
now
calling
the
serializer
for
you
right
on
your
behalf,
and
there
is
effectively
a
global
api
that
you
can
that
you
can
basically
use
to
say.
Well,
I
want
asp.net
to
not
use
system
text.js
and
I
wanted
to
use.
You
know
newtonsoft.json
right
and
there's
a
you
know
you
get
package,
you
can
bring
in
an
extension
method.
You
can
call
and
it's
it
has
the
same
property
that
you
described
stephen,
where
effectively.
A
There
is
a
huge
difference
in
terms
of
where
you
configure
this
and
where
you
actually
end
up
using
the
serializer
right.
But
that's
you
know,
and
you
could
argue,
that's
a
problem
or
a
design
fault.
You
could
also
argue
that's
part
of
why
it's
you
know
an
attractive
programming
model
that
aspen
that
provides
because
the
when
you
actually
implement
the
web
api,
you
don't
have
to
deal
with
the
mechanics
of
the
serializer
and
you
just
have
one
central
place
where
you
can
say:
oh
yeah
swap
out
system
text.json
for
new
soft
json
right.
A
E
E
B
It
will
just
work
so
if
yeah
by
work
you
mean
the
object
will
be
converted
to
bytes.
That
is
true.
It
will
work.
If
you
mean
the
format
of
these
bytes
will
be
interchangeable.
Of
course,
not
that's.
That
is
almost
the
whole
point
of
the.
A
B
G
B
A
Well,
I
mean
I
mean
in
the
web
api
case,
because
when
you
have
a
controller
like
there's
a,
I
guess,
there's
a
mime
type
right
and
so
long.
I
think
the
mime
type
is,
I
think,
part
of
the
abstraction
asp.net
has
because
yeah
it's
xml
versus
json
versus
whatever
right,
but
like
fundamentally
now.
The
question
is
that
that
abstraction
could
have
been
written
in
terms
of
here's.
A
mime
type
give
me
an
instance
of
objects
that
you
want
me
to
use
right
so
like
in
that
sense,
it's
portable.
A
I
mean
I
I'm
confused
by
what
you're
asking,
because
I
mean
if
you're
saying
you
don't
believe
that
you
can
actually
derive
from
object,
serializer
and
have
an
implementation
that
is
backed
by
protobuf.
I
mean
the
intention
wouldn't
be
that
protobuf
is
using
object,
serializer
directly
right.
The
idea
would
be
somebody
maybe
proto
above
themselves,
but
like
in
principle.
The
idea
is
that
it's
glue
right.
You
basically
derive
from
object,
sterilizer
and
you
basically
pass
the
data
through
to
protobuf
right.
So
it's
kind
of
an
you
know.
A
A
Oh,
for
sure
I
mean,
but
that's
also
why
I
think
the
api
ship
is
kind
of
the
way
it
is
right
because
it
just
deals
with
the
bare
minimum
that
you
would
think
you
know
you
would
ever
have
to
know
right.
Yeah,
given
an
instance
in
the
type
give
me
back
some
bytes
some
given
some
bytes,
giving
back
an
instance
of
this
particular
type
right.
That
seems
kind
of
intrinsic.
A
I
mean
the
only
problem
that
we
have
here,
which
is
what
we
discussed
on
the
on
the
on
the
thread
is
that
the
way
the
interface
here
is
defined
is
that
it's
all
effectively
not
friendly
for
static
generation
right,
because
it's
all
in
terms
of
object
and
system.type,
which
basically
means
it's.
It's
it's
implicitly
requiring
reflection
at
one
time
it's
very
hard
to-
or
I
would
say
it's
probably
impossible
to
tool
this
and
and
that's
kind
of
a
limitation,
but
I
think
that's
just
the
reality
of
today's
serializers.
For
the
most
part.
E
A
E
E
A
G
A
Same
way
as
in
they're
constrained
by
the
supply
type,
all
I'm
saying
is
that
you
know
in.
If
you
look
at
how
people
use
system
text.json
today,
it's
similar
to
system
to
to
newtons
of
json,
where
in
many
cases
the
call
site
isn't
generic.
In
many
cases,
the
calls
that
actually
this
does
take
an
object
into
system.type,
in
which
case
you
don't
know
statically
what
type
it
is
you
just
now
at
runtime,
the
payload
is
constrained
by
that
type
right
and
so.
A
Well,
it
is
discouraged
all
I'm
trying
to
say
is:
there's
a
difference
between
what
we
would
like
to
see
and
what
the
ecosystem
de
facto
does
right
and
the
the
fundamental
challenge
that
we
have
is
that
similar
to
async
the
problem
with
generics?
Is
that
they're
viral
right
and
so
like?
If
you,
if
you
look
at
how
code
plumbing
works
for
many
apps,
it's
just
not
viable
for
many
people
to
call
the
generic
overloads,
because
at
the
time,
what
they
have
to
call
it,
they
no
longer
have
a
generic
they.
A
The
only
thing
they
have
is
an
object
and
if
they're
lucky
a
system.type
that
actually
tells
them
what
instance
to
use
and
and
that's
why?
If
that's
what
I'm
saying
like,
if
you
look
at
the
history
of
serializers
in.net,
I
mean
christoph
and
me
and
many
others
on
our
team-
try
to
effectively
kill
civilization
for,
like
you
know,
quite
a
while.
We
try
to
get
reflection
out
of
the
core
right.
A
Maybe
when
we
try
to
do
that,
you
run
into
this
problem
that
real
world.net
user
code
is
just
so
dynamic
in
so
many
cases
that
it's
just
really
really
difficult
to
just
say
you
need
to
be,
you
know
generic
and
we
need
to
know
the
types
in
all
cases
right
and
that's
why
the
abstraction
looks
like
the
way
it
does
right.
I
mean
you
could
imagine
this
abstraction
being
completely
generic,
but
then
the
cosmos
db
folks
would
have
a
hard
time
plugging
that
in
as
well,
because
no
they
would
have
to
be
generic
as
well.
E
A
B
Well,
the
the
reason
so,
in
addition
to
the
object,
overloads,
genetics
would
be
just
fine,
but
a
lot
of,
for
example,
azure
sdk,
higher
level
libraries
like
the
cosmos
library.
B
C
B
It's
just
I'm
not
clear
what
it
would,
because
it
wouldn't
solve.
The
problem
of
you
know:
statically
not
being
able
to
see
what
what
what
is
the
set
of
serializable
types,
and
so
it
wouldn't
solve
the
problem
that
we
just
started
to
discuss
and
the
only
thing
those
genetic
methods
are.
They
are
just
syntactic
sugar.
C
A
Yeah,
I
think
the
question
is,
I
mean
I'm
trying
to
echo
like
the
concern
that
andy
has,
which
I
think
is
still
the
thing
that
we
need
to
kind
of
reconcile
with
the
design
here
is
like
so,
let's
say,
cosmos
uses
this
abstraction,
which
I
assume
they
already
do,
because
I
think
your
shipped
object,
sterilizer
in
in
in
the
azure
sdk
right.
So
if
you
now
have
a
customer,
let's
say
a
big
customer
like
exchange
with
somebody
who
actually
happens
to
use
cosmos
db
as
an
implementation
detail.
A
A
I
have
to
keep
all
the
metadata
around
just
in
case,
and
then
you
know-
or
I
do
the
good
old
windows
8
store
scenario
where
I
have
a
genomic
audi
xml
file
and
I
try
to
hand
pick
what
I
think
is
safe
and
then
eventually
I
get
to
an
app
that
works,
and
so
I
think
that's.
I
think
the
concern
is
that
if,
if
we
have
an
abstraction
and
it
it
becomes
widely
used
for
core
libraries,
we
don't
want
to
end
up
in
a
world
where
now
you
know
the
you
know,
you
know
the.
A
Unless
they
are,
you
know,
untrimmable
or
you
know
not
not
great,
for
these
kind
of
scenarios,
but
if
you
think
of
web
ap
and
not
bad
babies
or
if
you
look
at
web
assembly
or
or
xamarin
where
trimming
is
effectively
required,
for
you
know
decent
perf,
then
that
would
be
unfortunate
right.
We
don't
but.
B
The
thing
is
that
I
mean
to
me:
it
seems
like
the
ship
has
sailed
20
something
plus
years
ago.
Like
we
have
you
know
the
the
runtime
is
a
very
dynamic
system,
so
I
think
it's
great
to
think
how
to
make
you
know
the
trimming
better
and
you
know
the
scenarios,
but
I
don't
think
it's
a
you
know
we
can
pursue
hundred
percent
transability
guaranteed
by
all
the
apis.
In
bcl
I
mean
we
have
system.object
already
in
the
bcl.
Well,.
A
Well,
I
don't
think
that's
what
we're
saying
I
I
I
think
the
question
is:
if
you
look
at
an
api
design
where
you
have
generics
and
dynamic
methods-
and
we
have
attribution-
you
can
say
well,
things
are
linker
friendlier
if
you
call
the
generic
ones,
and
so
you
can
have
an
analyzer
that
says.
Oh
this
api
isn't
thinker
friendly
and
then
for
application
models
where
basically
linking
is
effectively
part
of
the
experience
like
web
assembly
or
xamarin.
Those.
A
Default
right
so,
like
you,
we
don't
have
to
dumb
down
the
system
for
everybody
right.
But
the
question
is:
if
I'm
in
this,
in
a
scenario
where
I
need
linker
correctness,
how
do
I
get
there
without
effectively
having
to
re-plumb
the
entire
theory
right,
and
I
think
that's
the
current
abstraction
of
this
proposed
would
basically
say,
like
oh
sorry,
you're
never
going
to
be
thinker
friendly.
So
if
you
have
any
call
sides
to
this,
you're
basically
screwed
and
I
think
that's
kind
of
the
concern.
B
B
E
B
But
I
I
think
I
the
only
thing
that
I'm
wondering
if
you're
thinking
you
can
remove
those
methods
that
take
objects,
because
I
believe
you
cannot,
it
has
nothing
to
do
with
azure
sdk.
It
has
all
to
do
with
many
high-level
libraries,
not
azure
sdk
other
libraries.
They
often
don't
want
to
be
generic.
They
often
take
objects.
So
if,
if
the
generic
methods
are
an
addition
that
you're
gonna
make
when
you
move
this
type
to
bcl,
I
think
it's
a
good
call.
E
No,
I
don't
think
that
dynamic
that
the
use
of
of
kind
of
dynamic
type
checking
and
reflection
in
net
core
or
anything
else
is
going
to
go
away
anytime
soon,
but
just
like
looking
forward
at
minimum.
I
think
we
should
support
the
systems
that
we're
already
building
for
reflection,
so
this
new
system
text
json
apis
that
use
source
generator
generation.
I
think
that
should
be.
I
mean
that's.
E
That
was
a
huge
amount
of
effort
for
a
lot
of
different
scenarios
and
we
should
make
sure
that
we're
not
kind
of
dropping
the
support
for
our
flagship
apis
in
our
flagship
abstraction.
If
this
is
going
to
be
our
flagship,
abstraction.
C
Yeah,
because
whether
it
goes
through
the
generic
one
or
it
just
dispatches
to
the
current
abstract
ones,
the
if
you've
run
the
source
generator
for
your
types
and
you're
trying
to
work
with
this,
you
basically
have
to
write
a
type
switch,
a
fall
to
say.
If
I
asked
for
this
type,
then
dispatch
to
this
pre-generated
type,
we
may
have
built
that
in
with
the
the
generated
output,
but
that's
basically
the
the
model
that
you'll
have
to
build
is
a
derived
type.
C
B
There
are
some
comments
and
I
saw
people
having
hands
up
in
the
chat
one
interesting
one
is
we
have
the
discussion
about
implementations
of
this
abstraction
and
pavel
commented
that
there's
also
I
forgot
about
it
in
azure
sdk,
an
implementation
that
uses
avro
as
a
format.
So
yes,
it's
not.
You
know
protobuf,
but
it's
actually
kind
of
similar
to
protobufs
has
a
there's
a
header
section,
and
then
it
can
be
either
text
or
binary.
So
there
is
more
than
just
json
implementations
of
this
abstraction.
A
Yeah,
if
we
say
flagship
in
abstraction
I
mean
that
might
also
be
a
bit
over
selling
what
this
is
for
like
the
way.
I
see
it
at
least,
and
I
think
the
way
the
azure
sdk
has
been
using
it.
It's
not
so
much
meant,
as
you
know,
if
you
do
civilization,
you
should
use
this
thing,
it's
more
for
if
you
happen
to
use
the
dynamic
civilization
mechanisms
that
we
have,
and
this
abstraction
allows
you
to
plug
in
others
or
let
the
users
plug
in
others
right.
A
So
it's
not
so
much
the
you
know
the
you
know
the
the
last
final
thing
to
do.
It's
more!
A
The
idea
that
you
know
we
are
adding
value
by
basically
saying
you
know
we
we
recognize
where
the
ecosystem
is,
and
we
make
it
possible
for
people
to
do
what
they're
already
doing
right,
we're
not
making
the
world
fundamentally
different
with
this
abstraction
right,
I
I
mean
you
could
imagine
that
you
know
we
have
a
different
abstraction
for
source
generation,
which
I
don't
know
what
that
would
look
like,
because,
fundamentally
that
is
way
harder
and
I
think
the
problem
that
we
still
run
into
with
system
text.json,
even
though
we
just
designed
it.
A
We
would
have
designed
system
text.serializer,
sorry
systemtext.json
from
day
one
with
sourcegen
in
mind,
but
we
didn't,
and
so
this
vector
actively
adding
on
top
is
what's
difficult,
and
I
think
that
is
a
problem
that
pretty
much
all
civilizers
have.
Some
like.
Protobuf
are
kind
of
designed
pretty
much
from
day.
One
of
saying
no
there's
a
schema.
The
schema
is
fixed
and
it's
independent
of
your
type
shapes
and
blah
blah
blah,
and
that
is
of
course,
more
friendly
first
for
a
generation
right,
but
I
I
think,
like
most
lessons
aren't
like
that.
A
Most
are
very
ad
hoc,
where
you
walk
an
object
graph
and
you
make
up
stuff
as
you
go,
and
then
you
introduce
some
attributes
or
some
random
callbacks
and
that's
kind
of
how
most
realizers
are,
and
so
the
I
wouldn't
necessarily
say
that
you
know
this
thing
is
the
future
for
everything
it's
more
like
the
make
the
existing
world
a
bit
more
exchange
friendly.
I
think
that's,
that's
how
I
would
see
that
which
I
think
adds
value
right.
So
to
me.
A
E
Yeah,
like
are
we
going
to
put
it
on
system
text
json?
Are
we
going
to
put
it
on
binary.
E
It
probably
not,
but
you
know,
data
contract,
xml.
A
Yeah
so
for
so,
I
would
say
system
text.json
for
sure,
obviously
right,
because
that's
where
it's
already
being
used
for
data
contract
with
xml,
I
can
see
because
our
xml
is
there
for,
for
that
matter.
In
general,
I
could
see
binary
formatter.
I
don't
think
we
would
touch
for
all
the
right
reasons,
and
then
I
would
think
that
maybe
in
asp.net,
where
they
actually
do
talk
about
the
sterilization
mechanism,
that
would
maybe
use
that
abstraction
over
what
they
currently
have.
E
In
that
case,
I
wonder
whether
it's
backwards
in
the
sense
of
we
know
where
we'd
like
to
implement
it.
Why
don't
we
do
that?
First,
rather
than
add
that
you
see
what
I'm
saying
like
we're,
adding
the
abstraction
before
we
actually
implement
the
abstraction,
but
it
seems
like
we
would
want
to
do
them
together.
A
Yeah
yeah
I
mean
like
so
I
mean
this
is
not
meant
to
be
a
discussion
for
let's
just
approve
what
we
have
right.
This
is
meant
to
be
a
discussion
of
like
do.
We
think
we
want
an
abstraction
at
all
right,
so
I'm
still
like
kind
of
at
step.
0.5.
If
you
will
right,
but
I
mean
I
in
general-
I
agree
like
if
you
have
an
abstraction,
you
ought
to
have
more
than
one
implementation
to
actually
verify
that
it's
you
know
a
useful
abstraction.
A
I
kind
of
waved
it
a
little
bit
in
the
sense
that
the
azure
sdk
already
has
implementations
for
system
text.json
and
for
newton's
of
json.
So
in
that
sense
it's
proven
enough
to
be.
You
know
useful
as
a
discussion.
I
don't
know
what
the
quality
is.
I
don't
know
what
the
you
know,
how
many
scenarios
it
can
handle.
A
F
Yeah
sure
the
implementations
are
actually
quite
good.
I
mean
I
haven't
looked
at
them,
but
the
developers
working
on
them
are
great.
I
think
the
question
would
be:
does
it
meet
the
more
generalized
needs?
I
mean
the
points
I
made
earlier
system
text.
Json
has
been
evolving
in
a
way
that
is
focused
on
trim,
ability
and
the
like
and
is
are
introducing
a
new
system
text.
Json
object,
serializer,
going
to
push
the
way
that
ends
up
violating
those
desires,
violating
the
goals
of
pushing
people
to
actually
use
the
source
generator
and
so
on.
E
And
similarly,
like
the
the
implementing
usage
point
I
was
trying
to
make,
was
that
really
it
should
be
both
sides
that
we
should
find
the
places
that
we
would
actually
use
the
abstraction-
and
I
think
you
know
cosmos
is
great,
but
they
already
have
the
abstraction.
What
what
are
we
really
gaining
there
by
adding
it
so.
B
For
abstinence,
as
an
example,
we
literally
have
probably
already
you
know
several
services
that
use
it
and
new
one
is
being
added
every
quarter
or
so.
B
What
we
are
doing,
we
can
keep
using
the
you
know,
azure
sdk
abstraction,
but
then
it
means
we
now
have
our
own
implementations
of
the
abstractions
for
both
neutron,
soft
and
text
system
text
json,
and
when
we
do
avro,
we
basically
like
it's.
You
know,
because
we
have
this
abstraction
and
it's
azure
specific.
E
H
H
I
don't
know
call
it
microsoft,
dot,
serialization
new
library
defines
this
abstract
class.
If
there's
usage
of
like
generally
purpose
one,
maybe
there's
a
you,
know:
newtonsoft
or
system
text
json
in
there
implementations,
if
there's
like
built-in
ones
that
we
need
in
that
library.
But
then
there
can
be
extension.
I
B
There
was
an
email
thread,
I
know
peter
dan
and
some
people,
some
people
from
your
side
and
some
people
from
our
side
are
on
the
email
thread
and
we
were
discussing
this
exact
issue,
which
is
we
have
libraries.
Basically.
Currently
we
have
libraries
that
are
in
the
pcl
or
in.net
platform.
B
We
have
libraries
that
are
in
azure
sdk
and
then
we
have
random
microsoft,
libraries
on
nougat
and
today
the
problem
is
that
some
things
are
so
general
purpose
that
they
don't
belong
to
azure
sdk,
but
the
bcl
team
is
not
willing
to
kind
of
take
ownership
of
of
these
libraries
and
the
third
alternative,
random
library
on
nougat.
The
problems
that
these
have
are
that
you
know
people
use
different
patterns.
B
They
they,
like
you,
know:
random
teams
at
microsoft,
ship
very
opinionated
libraries
that
don't
follow
really
design
guidelines,
some
principles,
how
you
build
them,
how
these
things
should
version.
So
there
was
an
idea
of
creating
a
repo
that
would
be
kind
of
you
know,
good
microsoft,
libraries,
and
maybe
they
go
through
some
light
api
review
like
this
one.
Maybe
we
kind
of
you
know
collaborate.
We
have
a
shared
api
review
or
microsoft
wide
api
review.
We
set
up
static
analysis
tools
in
this
repo.
We
set
up
a
build
system
such
that
you
know.
B
Nuget
packages
are
very
consistent
when
they
are
deployed.
There
is
an
idea,
I
don't
know
who
would
actually
like
make
it
happen,
but
I
think
it's
something
worth
considering
and
if
we
had
that
you
could
argue
that
you
know
a
type
like
this
should
be
there.
H
I
mean
kind
of
one
of
the
reasons
why
I
posed
this
question
is
because
I
don't
know
of
a
different
programming
platform
that
would
put
something
like
this
in
their
core.
Libraries
right,
like
rust,
has
30,
but
even
that's
not
built
into
rust.
Right.
Like
that's
a
separate
thing,
I
mean
granted
we've
kind
of
lived
with
20
years
of
anything.
That's
general
gets
put
in
the
bcl
in.net,
but
do
we
need
to
keep
doing
that?
I
don't
know.
Is
it?
Maybe
this
isn't
the
flagship
for
that,
but
I
keep
seeing
this
problem.
A
Well,
I
mean
to
me
it's
kind
of
there's
a
difference
between
putting
more
in
the
core.
Like
you
know,
somebody
on
twitter
recently
asked
for
building
yaml,
for
example,
right
and
having
abstractions
that
are
fairly
lightweight
to
allow
others
to
provide
stuff,
and
I'm
I'm
way
more
sympathetic
to
the
letter
and
way
less
sympathetic
to
the
former.
A
Or
what?
Because
that
is
a
fundamental
property
of
net
as
a
not
so
much
as
a
as
a
as
a
culture,
which
I
think
the
culture
is
the
yaml
problem,
because
everybody
expects
us
to
provide
it.
The
other
problem
that
we
have
is
you
know
the
type
safety
and
the
you
know
the
way
you
know
assemblies
work
right.
So
the
problem
is
if
somebody
else
needs
to
ship
an
abstraction,
it's
effectively
yet
another
new
nuget
package.
A
That's
yet
another
library,
it's
yet
another
moving
piece
in
the
system
and
that
causes
friction
and
so
far
you
know
we
have
done
a
lot
of
work
to
make
the
binder
less.
You
know
more
forgiving.
We
have
tried
to
make
new
get
dependencies.
You
know
less
annoying,
but
fundamentally,
like
nobody
likes
more
moving
pieces
right
and
that's,
I
think,
a
fundamental
property
of
of
of
our
type
system
and
delivery
artifacts.
That
has
nothing
to
do
with
culture.
That
is
just
to
do
with
you
know.
A
Do
we
do
we
want
this,
and
we
know
you
know
that
people
people
complain
all
day
long
and
it
we.
We
are
debugging
these
problems
all
day.
Long
too
right,
and
so
it
seems
to
me
it's
easier
if
there's,
if,
especially
when
it's
a
single
type,
because
putting
putting
a
single
type
in
nuget
package
is
never
great,
and
so
there's
a
there's.
Also
a
pref
argument.
I
mean
there's
many
other
cases
where
it
seems
desirable
if
the
thing
is
really
small
to
just
edit
right
but
like
if,
if
the
thing.
G
C
A
Right
I
mean
this
is
the
kind
of
the
other
problem
that
you
know
every
time
christoph
and
I
talk
right.
It's
the
you
know.
Yes,
we
can
put
it
in
the
platform,
but
no
it
doesn't
help
the
azure
sdk
because
they
need
to
run
on.net
standard
tool
right
so
but
there's
a
there's
a
there's,
a
difference
between
you
know
the
current
system
of
the
world
and
then
the
customers
who
happen
to
be
on.net
6.07.net,
eight
right.
So
at
least
you
can
say
well,
isn't
the
like
it
is
in
the
box
eventually.
A
J
A
A
B
Well,
I'm
also
not
sure,
if
that's
true,
what
do
you
mean?
We
didn't
put
it
in
the
vcl
as
far
as
the
ecosystem
is
concerned,
it's
in
the
bcl,
it's
not
in
the
short
framework,
but
it's
in
the
bcl,
and
I
think
that
is
the
middle
ground
for
some
of
the
apis
like
object,
serializer,
that
is
in
azure
sdk.
B
You
know
these
mappers,
that
maps
objects
to
bytes
the
moment
we
put
it
in
system
namespace,
it
can
be
a
nougat
package,
but
if
we
put
it
in
system
namespace,
there's
an
api
review
in
this
forum,
it's
approved,
it
kind
of
you
know
it
communicates
to
the
developers
in
the
ecosystem
that
this
is
that
type.
It's
basically,
you
know
endorsed
by
the
by
this
team,
and
I
think
binary
data
is
like
that.
B
It's
not
in
the
readers,
but
it's
endorsed
is
the
way
you
know
it's
a
simple
holder
of
bites
and
I
think,
object,
serializer
endorsed
by
this
group
would,
you
know,
be
treated
similarly
by
the
by
the
community.
The
question
whether
it's
something
is
in
the
shared
source
or
in
the
readers
or
not.
A
Yeah
to
me,
like
I
mean
eric,
can
correct
me
but
like
it
sounds
to
me
as
if
what
eric
just
suggested
that
this
middle
ground
and
what
you
just
said
is
virtually
the
same
thing.
It's
just
now
the
difference
between
system,
dot
and
microsoft,
dot
right.
A
And
I
think
that
is
kind
of
I
think
this
goes
back
to
what
I
said
earlier
about
more
like
the
cultural
thing,
but
I
think
for
things
like
an
abstraction
like
an
object,
serializer.
I
think
that's
probably
fine,
because
I
think
that's
one
of
the
examples
where
you
kind
of
want
fewer
things
anyway
and
I
think
an
abstraction
fundamentally
is
having
an
opinion
right
and
you
will
cut
off
some
scenarios
and
that's
fine
but
you're,
adding
value
by
providing
an
agreed
upon
abstraction.
A
The
problem
with
things
like
yaml
parsers
is
that
you
kind
of
want
to
say
like
well,
you
know:
do
we
really
have
to
have
an
opinion
on
everything
or
could
we
just
say
the
ecosystem
is
diverse
and
there's
multiple
different
yaml
implementations
and
you
pick
the
one
you
want,
and
I
think
this
goes
a
bit
back,
how
other
ecosystems
work
where
you
don't
have
to
have
an
opinion
on
everything
and
then
some
people
like
this,
some
people
like
that
and
that's
fine
and
I
think,
that's
generally.
A
Okay,
especially
when
you
have
good
enough
core
abstractions,
so
people
can
at
least
exchange
stuff.
They
don't
have
to
agree
on
every
single
type,
and
I
think
that's
that
to
me
would
be
the
middle
ground.
I
would
say
like
for
heavy
implementations.
Yes,
microsoft
doesn't
have
to
provide
everything,
but
everything
has
a
different
system.
Even
if
it's
provided
by
microsoft,
it
could
just
be
a
render
nuget
package
that
is
called
microsoft,
dot,
opinion
of
the
day,
dot,
nuget
package
right
and
those
things
might
not.
B
A
I
mean
to
me
that
kind
of
depends
on
the
abstraction
right.
I
mean
binary
data
because
it
its
implementation
dependent
on
system
text.json.
We
knew
it
would
be
very
high
right
this
one
here.
If
we're
looking
at
the
api
shape,
it
pretty
much
depends
on
only
stream,
so
it's
fairly
low
level,
so
it
could
live
virtually
anywhere.
We
wanted
it
to
live
in.
I
mean
in
order
for
us
to
be
able
to
give
it
to
you
for
net
sender.
2,
it
would
probably
have
to
go
in
its
own
assembly
would
be
my
guess.
B
But
I
wonder
whether
we
so
I
think
you
know
putting
it
very
deep
in
the
core
has
the
benefit
of
now
that
the
platform
itself
can
use
it.
That's
true,
putting
it
below
system
memory
data,
but
not
in
the
core.
I
know
what
you
said
that
you
know
system
memory.
Data
has
dependency
on
system
text
json,
but
I
think
that's
okay
system
text.
B
A
A
Where
does
the
live
discussion
right
and
they
are
almost
independent
right,
and
so
we
could
decide
that
the
uber
identity
is
its
own
assembly
and
then
the
inbox
assembly
is
actually
let's
say
we
could
you
know
we
could
go
all
the
way
down
and
put
it
in
system
runtime.
If
you
wanted
to
right,
I
mean.
B
A
C
G
C
Generally,
have
give
me
a
thing
and
we'll
do
load
save
for
you.
This
is
that's
what
this
is
for,
so
it
you
know,
most
of
the
of
the
shared
framework
is
functional
and
right.
While
there
were
a
few
things
that
basically
do
load,
save
that's
essentially.net,
remoting
and
that's
gone,
and
so
there's
no
benefit
to
being
in
the
shared
framework
and
our
current
rule
that
I
understand
is:
if
we
don't
need
it,
it's
not
allowed.
B
A
B
A
H
B
Yeah
and
then
there's
actually
not
two,
there
are,
there
are
many,
probably
json
serializers
and
it
allows
people
to
use
this
feature.
The
http
json,
whatever
the
feature
is
called
js
hp,
client,
json,
yeah.
It
allows
customers
to
use
this
feature
with
serializer
json
serializer
of
their
choice
and
in
fact
the
apis
are
called
json.
I
suspect,
there's
nothing
json
about
it.
The
the
object
is
just
being
serialized
and
pushed
into
the
request
content
or
when
it's
deserved,
it's
you
know
pulled
from
the
response
content,
so
it
could
work
for
xml
services.
A
C
Maybe
yeah
and
then
you
know
the
overloads
of
this-
are
system
text,
json
configuration
objects
and
yeah
I
mean
we
could
make
another
one
that
took
an
object
serializer,
but
this
it
doesn't
need
to
live
at
this
level.
This
was
all
done
as
extension
methods.
So
wherever
object,
serializer
lives,
it
can
just
slap
another
get
from
json
async
extension
on
http
client.
B
A
E
E
A
Yeah
yeah
yeah,
we
would
I
mean
we
would.
I
would
think
that
if
we
have
generic
methods,
we
would
make
the
generic
overloads
plum
through
the
generic
ones
right
and
then
this
way
it
would
close
that.
But
I
think
the
question
is
you
know
I
don't
know
like
I
mean
we
would
have
to
look
at
sample
code,
but
my
gut
feel
is
these
ones
here
that
actually
take?
A
You
know
the
the
json
serializer
options?
Are
it's
already
not
the
most
popular,
because
it's
you
know
making
this
thing
more
and
more
complicated
and
like
it's
really
meant
to
be
more.
Like
the
you
know,
the
single
line,
kind
of
implementation
of
your
of
your
service
right.
If
you
do
anything
that
is
actually
substantially
interesting,
you
probably
don't
call
these
apis.
Anyway,
you
contract,
you
basically
construct
the
syllabus
directly,
because
these
ones
are
really
like
immediately
calling
the
serializer
right
they're,
not
like
the
cosmos
db,
one
where
some
significant
amount
of
work
is
happening.
A
A
Like
this
one,
I
mean
to
the
earlier
question
of
like
readers,
I
mean
we
don't
have
one
readers
where
we
have
multiple
layers
of
shared
frameworks
right
so
the
the
way
I
see
it
is
you
know
the
microsoft
macro
app,
which
is
the
you
know,
the
fall
intensive
purpose
is
what
5o
represents
the
basically
what's
auto
reference
when
you
build
a
console,
app
or
a
class
library,
you
know
an
abstraction
would
still
add
value.
In
my
opinion,
if
other
shared
frameworks
that
sits
on
top
would
use
it
right.
A
So,
for
example,
imagine
there's
a
shared
framework
for
maui
there's
one
shared
framework
for
asp.net
and
they
both
want
to
use
it.
Then
it
might
make
sense
to
put
the
abstraction
into
the
shared
layer,
even
if
the
shared
layer
below
them
doesn't
actually
use
the
abstraction
themselves
right,
and
I
think
it's
fair
to
say
that
you
know
the
microsoft
network.
App
is
probably
not
very
likely
to
use
the
abstraction.
A
You
know,
with
the
exception,
for
this
api,
for
example,
but
like
for
the
most
part,
I
would
expect
this
to
be
plumbing
and
then
the
app
models
would
have
an
opinion
on
and
they
might
actually
use
it.
And
if
multiple
app
models
are
using
it
to
me,
it
makes
sense
to
have
it
in
that
crap
to
remove
duplication
but
yeah.
There's
fundamentally
nothing
wrong
with
saying
shift
is
a
new
get
package
and
then,
let's
say
the
asp.net
shared
framework
has
it
in
it,
but
microsoft
net
core
app
doesn't
right.
A
Those
are
the
decisions
that
we
can
make
and
I
think
in
general,
like
if
you,
if
you
do,
build
an
abstraction,
I
would
start
with
an
oop
just
to
and
in
order
to
get
some
feedback
work
with
other
third
parties
as
well
to
make
sure
that
they
can
implement
their
stuff
on
top
of
it
if
they
wanted
to
christoph.
Did
you
actually,
like
you
own,
the
newtons
of
json
implementation
right.
B
B
E
C
G
C
Which
also
came
up
in
the
youtube
chat
of
is
stream
really
what
we
would
base
this
on,
like
a
lot
of
work
has
been
done
recently
to
reduce
object
allocations,
and
if
you
have
a
span
now
we're
saying
you
have
to
take
the
span
and
write
it
into
a
memory
stream
to
pass
it
to
deserialize
and
well.
But
why
couldn't
deserialize
just
take
the
span
and
that
would
also
have
impact
on
layering
decisions
and
the
like.
C
But
so
I
assumed
that
what
we
were
talking
about
in
this
hour
was
what's
the
value,
slash
cost
of
the
concept,
and
so.
H
E
And
you
can
fix
it
with
generics,
but
you
got
to
be
very
careful
about
it
as
the
results
from
like
the
source
generation
show
like
it,
it's
tricky.
I
wouldn't.
I
wouldn't
underplay
the
amount
of
api
design
that
would
yeah.
C
E
E
And
so
at
the
other
end,
if
we
decide
that
we
build
an
abstraction
that
we
don't
think
would
ever
be
usable
in
blazer
or
something
like
that,
then
you
know
go
for
it
right,
but
it
just.
I
didn't
see
a
reason
why
we
would
think
that
these
things
wouldn't
be
useful
in
blazer
or
in
mobile
apps,
or
anything
like
that.
A
If
you
have
yet
I
mean
we
already
had
the
discussion,
I
think
when
I
mean
we
initially
built
the
http
client
extension
method,
specifically
for
blazer,
and
then
when
people
tried
to
use
the
linker
on
it
like
bad
things
happened
right,
and
so
that's
the
this
is
what
I
said
earlier
about
like
retroactively
making
that
so
like
I
totally
take
the
feedback
that
you
know.
E
A
You
know
I
mean
that's,
I
think
a
good
question
in
general
is,
like
you
know,
even
like,
given
that
it's
gen
that
this
is
an
abstraction
like.
Is
it
always
lossy
effectively
for
the
type
system?
And
the
answer
is
probably
yes
right,
but
that's,
I
think
something
we
should
think
about.
So
then,
okay,
I
have
a
bunch
of
notes.
A
Let
me
just
paste
them
in
here
and
then
you
can
take
a
look
and
tell
me
whether
I
missed
anything,
but
I
think
this
was
a
useful
conversation
and
then
I
think
the
the
follow-up
would
be.
A
B
Yeah,
I
think
it
would
be
good
to
add
those
genetic
methods
and
kind
of
do
more
thinking
about
how
it
would
integrate
with
blazer
and
other
environments
that
require
trimming.
Also.
I
think
it
would
be
good
to
make
the
proposal
a
bit
more
like
concrete,
for
example,
which
concrete
binaries
we're
putting
it
in
and
maybe
there's
a
kind
of
progression
sequence
like
initially.
We
just
put
it
in
system
memory,
data
oop
package,
and
then
you
know
potentially
what
happens
when
when
we
put
something
like
this
in
the
core,
because
it
would
have
implications
on.
B
B
Correct
it,
it
would
have
to
operate
on
probably
memory
of
byte
and
then
the
azure
abs,
corresponding
abstraction,
like
one
additional
thing
we
would
want
to
do
is
since
we
already
shipped
the
abstraction
in
azure
core,
we
would
want,
if
we
add
dcl
abstraction.
We
would
want
our
abstraction
to
inherit
from
the
from
the
core
abstraction.
B
E
C
E
C
Once
we
want
anything
to
have
a,
I
guess
we
have
dims
now,
but
not
for
net
standard
2o.
As
you
can
see
once
we
want
to
have
the
virtual
generic
that
dispatches
to
an
abstract
in
terms
of
object
and
type,
then
now
you're
a
class.
E
E
C
It's
dims,
which
I
know
that
I
still
have
to
deliver
the
write-up
on
when
we
think
we
might
be
able
to
use
them,
but
basically
we
haven't
used
them
yet.
So
that's
that
standard
2o,
sometimes
forces
us
into
the.
We
can't
even
discuss
it
anymore,
but
dems
themselves
have
proven
to
still
be
a
problem
for
us.
A
Yeah
I
mean,
regardless
of
dims,
I'm
just
genuinely
very
skeptical
of
interfaces
for
things
like
that.
Right
I
mean
if
the
interface
literally
is
super
simple.
It
has
one
method
on
it.
I
can
see
it
as
soon
as
you
talk
about.
Oh
what,
if
we
want
to
support
other
types
in
the
in
the
future,
you
kind
of
talk
about
a
type
you
want
to
evolve
and
to
me,
dims
are
not
really
as
as
easy
to
use
as
that's
the
virtual
methods
are
in
classes,
and
so
I
would
generally
say
like
unless
there's
a
good
reason.
A
I
would
not
change
our
guidelines
to
go
from.
You
know,
interfaces
to
from
classes
to
interfaces
just
for
aesthetics
right,
which
is
kind
of
what
most
of
the
discussions
that
actually
in
the
past
pushed
for
interfaces
were
literally
based
on
it's
not
there
really
isn't
the
reason
why
you
can't
use
an
abstract
class
for
the
most
part.
E
C
A
So
yeah
I
mean
the
question
really
boils
down
to,
like
I
mean
if
we,
if
we
want
to
like,
I
think
for
abstractions,
it's
fine,
if
you're
a
bit
more
constrained
in
terms
of
you
know,
you
can't
just
use
the
latest
feature
if
your
goal
is
to
have
an
abstraction
that
gets
uptick
by
the
ecosystem
on
day.
One
right,
if
you
build
something
completely
new
like
span
where
you
say
that
okay,
we're
adding
a
ton
of
value
here,
but
it
will
take
a
while
for
the
ecosystem
to
catch
up.
A
That's
also
fine
right,
but
I
think
the
the
problem
is
always
when
you
build
something
that
is
super
sexy,
but
nobody
can
use
it
yet,
then
the
uptake
is
super
super
super
low
right
and
that's
kind
of
the
catch
22
that
we
try
to
avoid.
So
in
that
sense,
I
think,
even
if
you
put
it
in
box,
I
wouldn't
necessarily
say
like
okay:
let's
go
out
of
our
way
to
make
it
impossible
to
provide
a
net
standard
to
implementation,
which
I
think
in
this
case
would
kind
of
look
like
that.
A
In
my
opinion,
because
I
mean,
if
you
just
designed
it
naturally,
I
think
you
would
have
something
that
just
works
on
that
standard
too,
and
then
it's
just
a
function
of
like
do.
We
think
that's
the
right
thing
of
doing,
but
I
did
this
whole
write-up
to
actually
talk
about
what
the
trade-offs
are
right
and
I
think
I'm
I'm
not
morally
opposed
to
do
that,
because
I
mean
there's
business
value
in
doing
so,
and
I
think
that's
where
we
have
you
know
I
have
to
make
the
decision
all
right.
B
E
B
E
Is
probably
the
expert
after
doing
all
that
source
generation
system
text,
json
work
and
then,
in
terms
of
you
know
the
things
that
the
linker
can
recognize
and
the
features
we
support?
I
think
I
would
be
a
good
contact
for
that.
E
Yeah
yep,
the
other
thing
I
would
add,
is
system
text
json
the
non-polymorphic
mode.
E
C
E
A
A
All
right
so
then
we
have
30
minutes
over
time,
but
I
think
it
was
a
good
discussion.
I
I
basically
put
it
in
in
7-0,
so
there's
some
urgency.
I
mean
it.
You
know
it
doesn't
really
mean
that
it
only
ships
in
seven
all
right
that
can
still
be
an
oop,
but
you
know
in
terms
of
release
management.
That's
how
we
think
about
this.
E
All
right
for
for
context
when
we're
exploring
trimming
serializers
are
easily
the
biggest
problem.
You'll
see
something
like
60
of
all.
Warnings
are
related
to
trimming
in
our
experiments
very
sorry,
related
to
serialization
when
driving.
A
E
A
E
Personal
project,
I
can't
really-
I
can't
really
put
any
more
emphasis
on
it
than
that.
I
I
think
it's
both
a
proof
of
concept,
and
I
think
it's
probably
I
mean
personally.
I
would
like
it
better
because
it
turns
every
serialization
failure
into
a
type
system
error,
so
that
is
one
particular
way
to
program
in.net.
E
I've
yet
to
implement
so
it's
a
port
of
rust's
certi
by
the
way,
and
it's
very
similar
to
the
whole
idea,
solid
source
generated
and
it's
based
off
of
interfaces.
The
main
thing
is
that
serialization
is
an
interface
that
you
have
to
implement
kind
of
throwback
to
the
old
eye.
Serializable
stuff,
but
source
generators
really
changed
that
game.
A
Yep
that
makes
sense
all
right.
I
will
talk
to
you
offline,
whether
we
can
put
this
on
the
calendar
at
some
point,
because
I
think
that
would
be
interesting
to
a
lot
of
to
a
large
chunk
of
people
and
then
we
have
it
recorded
for
all
eternity
all
right.
So
then,
I
think
this
is
it
for
today,
unless
somebody
else
has
to
say
something.