►
From YouTube: .NET Design Review: GitHub Quick Reviews
Description
-15:-41:-49 - Approved: Json serializer support for a property name policy https://github.com/dotnet/corefx/issues/36351#issuecomment-483773918
00:38:51 - Approved: Evolving EventCounter API https://github.com/dotnet/corefx/issues/36129#issuecomment-483778953
00:48:31 - Approved: Add missing async methods in System.Data.Common and implement IAsyncDisposable https://github.com/dotnet/corefx/issues/35012#issuecomment-483779404
A
B
C
Okay,
I
I
guess
I
can
start
here
now
right
now,
Eric's
not
here,
but
we
did
kind
of
work
together
on
this
and
James
also
was
involved
with
some
discussions
here,
and
this
is
kind
of
what
we
came
up
with
it's.
Basically,
we
need
support
for
changing
the
way
a
property
named.
C
Our
local
object
is
handled
so
we're
proposing
four
things
here,
an
attribute
that
you
can
specify
explicit
name
just
say:
hey:
here's,
the
name
of
the
property,
no
other
post
processing
occurs
on
that
the
Nestea
attribute
and
then
two
properties
on
the
options
class,
the
serializer
and
then,
along
with.
That,
then,
is
one
of
the
properties
returns
of
class
and
we
provide
a
base
class
for
that
with
with
a
property,
aesthetic
property
to
get
the
default
key
location
policy,
we're
not
providing
any
other
policies
like
snake
case
in
etc,
out-of-the-box.
C
But
by
default
property
names
on
you
know,
on
a
polka
object
or
typically
Pascal
case
and
in
a
lot
of
cases
the
underlined
Jason
is
camel
case.
You
know
starts
to
the
lowercase
letter
so
that
so
basically
it's
very
common
that
the
Jays
son.
Then
we
have
to
be
able
to
convert
the
Jason
hommes
property
names.
We
have
to
be
able
to
match
those
up
with
the
Polka
object,
which
is
Pascal
cased,
and
that
policy
allows
you
to
do
that
and
then
case.
C
Insensitivity
is
another
thing
related
to
the
property
name
and
then
that's
kind
of
independent
of
the
name,
because
you
need
camel
case
or
whatever
or
not,
and
then
in
still
want
your
property
name
to
be
case.
Insensitive
when
your
DC
Rises.
B
C
Okay,
great
yeah,
that
was
this
is
what
we
started
with.
Originally,
we
had
a
way
to
specify
it
on
a
per
type
and
even
up
for
property
level,
but
for
preview
five.
This
is
what.
C
C
Yep,
so
yes,
and
then
on
with
it
with
the
jason,
are
with
the
jason
name
attribute,
you
can
have
any
policy
you
want
right.
I
mean
you
just
have
to
put
it
under
appropriate.
B
C
Exactly
so,
if
you
put
jason
name,
that's
exactly
what
its
gonna
be
irregardless
of
any
kind
of
global
study.
A
F
E
Is
case-insensitive
preferred
over
ignore
case
looks
like
we
have
a
mix
of
both
across
the
framework,
depending
on
whether
you're
working
with
like
string
or
a
collection
or
reg
ex
cetera,
so
ask
again
like
it
like
its
case-insensitive
versus
ignore
case.
Preferred,
oh,
you
mean
the
yeah
so
like
should
we
name
it
property,
name,
case-insensitive
or
a
property
name
ignore
case
we
seem
to
have
a
mix
of
both
usages
across
the
framework,
depending
on
what
you're
dealing
with.
C
Indicate
the
default
to
be
false,
I'm
open
to
naming.
E
A
F
C
Here
we
are
with
that
normalizing,
the
the
Jason
name
coming
in
to
Indian
culture.
C
Is
that
we
take
the
EJ's
the
name
coming
in
on
the
you
know,
on
a
deserialize
and
we
normalize
it
meaning
in
this
case
you
know
we
converted
to
uppercase,
but
what
they
could
do,
lowercase
using
the
invariant
culture,
and
then
we
compared
against
our
internal
cache
of
the
property
names
word
trip,
which
were
also
normalized.
The
same
way.
A
C
C
A
B
A
So
what
you
do
in
ten
people
to
be
able
to
inherit
from
this
right
see
what
you
would
need
to
protect
a
constructor
on
Jason,
a
policy
I
mean
if
you
write
the
code
like
this
in
c-sharp.
That
means
the
compiler
will
omit
the
the
protected
one,
but
an
API
reviews.
If
this
is
the
metadata,
that
would
mean
that
you
don't
have
a
constructor,
so
nobody
couldn't
have
it
from
this.
You
want!
Oh
okay,.
A
B
C
Yeah,
it's
kind
of
during
the
warm-up
phase,
look
through
all
of
the
properties
and
detect
this
global
setting
and
then
cache
it
and.
F
G
You'll
want
to
convey
the
idea
that
you're
not
doing
a
case
insensitive
comparison
of
the
data
coming
across
a
wire
against
a
property
name
on
the
type.
The
idea
that
you
want
to
convey
is
you
normalize
both
names,
and
then
you
do
an
ordinal
comparison
at
both
names
against
that
bit.
Actually
does
matter
good
reason
that
you
acknowledge
the.
G
If
you
have
a
lowercase,
dauntless
Turkish
line
and
compared
against
a
regular
capital
I
that
will
pass
as
true
for
ordinal
ignore
case
comparison.
But
if
you
have
a
lowercase,
dauntless
Turkish
high
and
you
call
to
upper
invariant
on
it,
it
will
return
back
the
original
lowercase
dauntless
Turkish
I,
which
no
longer
compares
as
equal
to
a
capital.
I
like
there.
There
actually
is
a
difference
between
normalization
and
ordinal
ignore
case
comparison.
C
G
A
G
G
A
D
C
I
G
Whatever
you
said
here
in
variant
culture
in
your
case,
hopefully
I
want
to
know
if
it's
ordinal
in
your
case,
then
this
behaviors
interval,
because
now
you
have
now
you
now,
someone
can
send
you
data
which
won't
bind
to
a
property,
but
where
you
look
up
that
exact
property
name
inside
the
leftover
data
dictionary.
What
we're
trying.
G
A
Still
don't
understand
why
normalization
is
more
efficient,
though,
because
to
me
like
you,
basically,
you
basically
read
the
payload.
You
take
the
string,
that's
in
the
payload
and
you
look
up
a
property
somehow
in
your
in
your
cache
things
meters,
the
dictionary
lookup
in
you
have
to
agree
on
what
the
comparator
using
so
no
matter
like
you
either
we
say
if
you
set
this
to
true
we're
using
ordinal.
If
you
set
this
to
false
sorry,
if
you
set
this
to
true,
we
are
saying
or
don't
ignore,
case
and
set
it
to
false.
It
means
ordinal.
C
Because
of
the
way
the
hash
table
is
structured,
it
does
byte
wise
comparisons
at
once.
After
the
normalization
occurs.
That's
why
I
mean
I.
If
we
don't
want
to
do
byte
wise
comparisons
for
the
key,
you
know,
that's
just
a
perfect
and
I
have
to
say:
okay,
if
property
name
is
insensitive
and
take
this
other
slower
path,
otherwise
you
know:
do
the
best
map
just
go.
G
That
might
be
the
best
time
to
do
right
now,
honestly,
just
so
that
we
don't
paint
ourselves
into
a
corner
when
you
say
this
would
you're
affected.
If
this
were
we,
we
don't
have
a
backing
store
of
normalized
names
where
we
compute
stuff
on
the
fly.
Yeah
I'm,
but
I-
don't
really
want
to
sidetrack
this.
On
implementation,
details
I
was
trying
to
figure
out
if
this
actually
affects
the
API.
A
C
I
know
early
on
or
something
goals,
of
course
were
high
performance
for
the
serializer
older
functionality
yeah.
But
you
don't
want
to
subscribe
all,
though
that's
the
thing
we
don't
want
to
do
the
wrong
thing.
So
if
this
is,
you
know
a
very
rare
thing
to
do,
and
it's
gonna
be
a
surprise.
People
then
find
we
should.
You
know,
probably
change
it
and,
like
I
said
it
already
has
a
performance
concern.
C
But
now
you
know,
if
you
a
lot
of
properties
on
your
vocal
class,
basically
have
we
have
to
fall
back
to
a
different
algorithm,
much
slower
over
in
your
dictionary.
Basically.
I
G
G
A
G
What
I
mean
is
you
can't
call
convert,
name,
cash
them
and
then
say
we
expect
only
these
exact
things
to
be
inbound
from
where
you
say
that
would
be
incorrect.
G
It
just
means
we
would
need
for
the
convert
name
proper.
For
that
convert
a
method
we
would
want
to
say
this
method
is
only
intended
to
be
used
during
the
serialization.
You
shouldn't
call
this
and
catch
the
results
in
order
to
speed
up
this
orientation,
behavioral
good
you,
you
will
potentially
deserialize
along
Dale,
where
you'll
potentially
perform
incorrect
decisions,
meaning.
C
Well,
I
mean
we
can
talk
about
the
implementation
later,
but
I
mean
my
assumption
is
that
we
can
catch
the
result
from
convert
name
regeneration.
I
G
A
C
A
A
G
F
G
G
G
G
G
A
Basically,
logically,
is
if
you
say,
compare
these
two
strings
and
before
and
in
comparison,
that
is
case.
Insensitive
is
different
from
saying.
Let
me
convert
both
strings
for
a
casing
to
upper
or
two
lower
and
then
compare
the
results.
Provide
equality,
correct,
they're,
not
result
in
the
same
output.
A
All
right
so
then
I
think
my
only
other
question
was
earlier
like
should
this
be
spam
based,
but
given
the
V
cache
name,
it
seems,
like
you
know,
the
payload
sizes.
You
know
the
other
dude,
sorry
that
the
types
are
finite.
So
no
matter
how
many
requests
you
get
per.
Second,
you
can
pre
catch
them.
If
you
really
want
to
do
the.
I
A
C
C
C
A
C
A
D
C
C
C
Okay,
if
there's
not
any
more
comments
on
it,
I
did
have
a
couple
quick
questions
for
feedback
on
behavior
other
than
what
I
haven't
need
to
discuss
with
Levi
afterwards
about
normalizing
right
now,
I
mean
I,
know
this.
Isn't
this
really
design,
but
what's
the
general
thinking
like
if
one
of
these
policies
would
return
a
null
or
an
empty
string?
Should
we
just
ignore
that
or
does
it
make
sense
to
throw
them
I.
G
Like
within
the
framework,
we
generally
don't
care
about
our
dependencies,
we're
turning
bad
data
to
us
generally,
we
just
know
rough
or
something
like
that
really
now,
generally
speaking
like,
if,
if,
if
we
call
a
virtual
method
on
our
own
type,
for
instance,
because
maybe
someone
some
class
test
like
we
generally
don't
defend
against
the
virtual
method,
returning
all
like,
we
generally
just
keep
our
people
also.
If
this
is
hooked
up
with
bulla
Ville
and
well,
it
doesn't
return
a
no
little
string.
A
G
B
A
A
B
A
A
C
But
back
to
yeah
you
can't
really
have
a
empty
property
name
and
a
poco
object,
but
I
mean
it
would
be
Villa
Jason.
So
you
could
put
it
in
a
property
there
or
something
like
that.
And
then
you
know
we,
the
converter.
We
could
special
case
empty
string
out
before
we
call
the
converter,
assume
there's
no
conversion,
but
someone
might
want
to
say:
hey
I
want
to
convert
an
empty
string
into
something
else.
Who
knows
so
I'm
inclined
just
to
leave
empty
string
alone
and
then.
J
A
Only
thing
I
would
say
is
like
I
think
the
way
you
would
do
this
is,
you
would
just
put
a
Jace
name
attribute
on
the
property.
You
want
to
be
the
empty
string
like
I.
Don't
think
it's
a
very
likely
scenario
that
you
want
to
be
able
to
take
a
non
empty
property
converted
to
empty
or
take
an
empty
one
and
it'd.
Make
it
non
empty
right.
J
A
they're
sort
of
orthogonal,
because
the
attribute
implies
that
you
own
the
type
and
can
change
it,
and
the
name
applies
to
anything
that
you
walk
through
the
serializer
or
sorry.
The
policy
is
anything
that
you
can
walk
through
the
serializer.
So
if
you
wanted
to
replace
everything
name
to
do
it
with
empty,
then
there's
no
way
to
do
that
without
letting
us
let
him
to
go
through
I.
C
Yeah
thrown
on
then
okay.
My
other
question
rate
someone
related,
is
in
the
sense
of
the
egg,
where
I
guess
is,
if
you
have
case
insensitive
or
you
have
camel
casing,
and
it's
not
possible
that
you
have
the
same
property
on
this.
Oh
sorry,
the
same
Jason
property
coming
in
that
can
map
to
more
than
one
focal.
You
know
property
right
now,
I
mean
in
the
implementation.
It's
just
not
defined
because
you
know,
like
whatever
reflection
orders.
You
happen
to
find
whatever
property.
First
I
don't
know.
If
I
should
special
case.
C
C
Are
we
just
is:
is
none
undefined,
okay,.
C
C
C
I
C
G
G
G
C
C
But
yeah
it
is
cached
and
only
done
once.
Forgive
us
hope.
C
A
A
B
E
B
B
Yeah
I
guess
I'm
asking
two
things.
One
is
exactly
what
you
just
said,
and
the
other
is
who's
generally
responsible
for
calling
cancel
a
sync.
My
intuition-
and
this
could
be
entirely
wrong
since
I'm,
not
particularly
I,
haven't
used.
Db
command
in
like
ten
years
is
generally
with
a
cancel
method.
You
would
do
something
like
cancellation,
token,
dot
register
and
the
delegate
you
pass
call
something
like
cancel
right
so
that
when
the
cancellation
token
is
triggered,
it
calls
cancel.
B
G
B
G
B
Suppose
they
think
is
special,
so
the
the
reason
we
chose
value
task
is
its.
While
most
implementations
will
probably
just
end
up
returning
a
value
test
that
wraps
a
task
or
that's
just
default,
because
it's
already,
you
know
complete
synchronously.
There
are
going
to
be
a
fair
number
where
it
actually
can
be
sort
of
the
more
sophisticated
implementation
that
we
use
as
an
existing
object
and
in.
B
All
of
the
async
generators
the
compiler
generates,
do
that
the
same
object.
That's
used
for
the
enumerator,
that's
used
for
the
services
for
the
innumerable
is
used
for
the
enumerator
is
used
for
every
value
task
returned
from
move
next
async
and
it's
also
used
as
the
backing
for
dispose
a
syncs
result.
Yeah.
B
G
B
A
J
J
J
A
B
I
know
shy
thoughts
through
these
and
was
sort
of
taking
into
account
my
guidance
that
unless
it
was
perfect,
it
should
return
tasks
and
perf
critical
on
the
async
completion
path
and
radicular,
I'm
masu
I,
don't
know
why
I'm
having
trouble
understanding
why
clothes
async
would
be
valued.
Tasks
could
be
worth
asking
him
and
maybe
there's
some
scenario:
I'm,
not
sure
what
the
scenario
would
be.
They.
B
While
disability,
because
Bo's
they
think,
could
call
closed
I,
think
that
would
be
fine,
because
you
can
wrap
a
value
task
around
a
task.
You
couldn't
do
the
opposite,
you
couldn't
have
well,
you
could
have
I
mean
close
I.
Think
could
shall
wait
to
suppose
they
think
it
would
just
be.
Oh,
be
an
async
implementation
yeah.
It's.
G
Just
they,
but
if
I
were
if
I
were
designing
this
like
if
I
have,
is
this
those
method
calling
a
closed
method?
I
would
probably
just
or
ease
of
understanding
that
will
be
just
propagate
the
return
type
because
it'll
mean
yeah.
It
just
wouldn't
occur
to
me
that
one
is
implicitly
convertible
to
the
other
right.
C
J
B
B
B
B
A
A
B
Was
trying
to
understand
how
expensive
clothes,
actually
it
I
get
clothes
implies.
You
have
to
open
a
brand
new
connection
and
do
all
those
round
trips.
Then
it's
definitely
expensive
and-
and
it's
not
just
a
close
call
that
matters
it's
what
you
do
to
get
another
connection.
But
if
clothes
async
is
just
putting
the
connection
into
a
collection
and
then
the
next
time
you
go
to
say
open
it
just
grabs
it
from
the
collection.