►
From YouTube: GitHub Quick Reviews
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
this
issue
is
about
adding.
Are
you
recording
now.
A
Okay
yeah,
so
this
issue
is
about
adding
adding
customization
for
the
serial
serialization
of
of
of
types
in
in
dot
nets
for
for
json,
so
specifically,
specifically
like.
Actually
it's
gonna
be
easier
to
just
show
an
example
like
what
kind
of
customizations
that
would
allow.
So
maybe,
let's
start
with
the
second
example
which,
which
is
something
we
already
have
in
that
net-
would
be
data
contract
attribute,
so
example
customization
you
could
do.
A
Is
you
specify
your
resolver
you
inherit
from
the
default
one
we
provide
as
the
as
json
implementation
and
the
contract.
Specifically,
what
we
call
contract
is
json
type
inference
here
and
json
type
info
contains
all
of
the
stuff
we
we
need
for
the
serialization.
So
specifically
here.
If
we
are
theorizing
objects,
we
have
things
like
properties,
we
have
also
other
knobs.
A
So
in
this
specific
example
like
we're
going
to
remove
all
of
the
properties,
we
have
on
the
contract,
we're
going
to
get
all
of
the
properties
with
the
data
member
attribute
by
reflection,
we're
going
to
order
them
by
the
the
order,
order,
property
on
the
attribute
and
we're
going
to
add
them
back
to
the
contract.
So
in
here
like
we,
we
also
specify
like
method.
A
How
do
you,
how
do
you
get
value
of
that
specific
property
given
the
given
the
object,
which
happens
to
just
match
the
merge,
the
reflection,
getter
and
setter,
and
also
we
do
the
same
for
the
setters.
So
in
this
specific
example,
we
basically
constructed
simple,
simple
contract
for
serialization
that
civilization
using
data
contract
attribute.
So
another
example
of
things
you
can
do
is
basically
construct
a
contract
for
like
how
to
serialize
like
a
specific
type
from
the
scratch.
A
So
an
example,
I've
created
a
simple
type
like
my
type
with
which
has
couple
of
like
maybe
weird
properties,
so
it
has
like
a
name.
It
has
a
string
id
for
whatever
reason
and
then
with
property
like
height
name
like
it
knows
like
what
someone
would
do
with
this,
but
anyway,
like
in
this
specific
example.
A
Like
we
put
some
couple
of
couple
of
values
into
the
array,
then
we
serialize
the
array,
and
then
we
can
control
things
like
if
the
id
will
show
up
at
all,
in
example,
here
like
because
id
is
minus
one
we're
not
gonna
show
it
make
make
it
show
in
the
in
serialized
array,
also
the
that
we
can
control
that
the
name
doesn't
show
up
by
doing
stuff
in
inside
of
the
contract
and
and
and
basically-
and
I
think
we
hopefully
want
to
achieve
so
like
the
way.
A
The
way
we
would
achieve
this
is
following.
So
on
the
options
on
the
adjacent
serializer
options.
You
normally
pass
to
the
serialize
method.
You
specify
your
custom
custom
resolver,
so
you
set
up
typing
for
resolver,
which
would
be
in
here
my
my
custom
type,
my
custom
resolver,
which
inherits
from
the
default
implementation
and
we
override
the
method
get
type
get
type
inputs.
You
can
also
do
it
by
constructing
this
completely
from
the
scratch
without
using
the
default
implementation.
A
There's
an
interface
we've
provided
for
that
which
the
default
registration
type
info
resolver
also
implements,
and
you
can
either
use
that
from
the
scratch
or
or
you
go
with
start
from
the
start
from
something
something
which
provides
lots
of
defaults
like
like
in
here.
So
in
this
specific
example
like.
If,
if
it's
not
our
type,
we
basically
okay,
we
we
do
whatever
the
default
does,
and
we
ignore
everything
else
and
in
other
case,
like
we
start
with
constructing
empty
contract,
and
then
we
provide
the
create
object
method.
A
Without
this,
you
wouldn't
be
able
to
deserialize
because,
like
the
the
json
serializer,
wouldn't
know
like
how
to
construct
the
type
after
that
we
create
property
id,
which
I
call
prop
id
in
here
and
you
do
it
by
doing
the
json
type
info,
dot
create
json
type
property
info
of
integer,
which
is
the
the
type
for
the
property
you
specify
getter,
you
specify
setter,
and
then
you
can
also
specify
options
like
can
serialize,
which
depends,
depending
on
the
value
you
can
decide,
and
the
runtime
if
the
value
would
be
serialized
or
not.
A
This
is
like
in
case
someone
has
their
own
defaults.
Like
in
example
like
for
integers,
the
default
value
for
integer
would
be
zero,
so,
like
normally
you,
you
have
an
option
to
spec
to
to
ignore
those
values
for
for
serialization
but
like
if
you
want
to
change
that
to
something
else
like
minus
one
or
something
else,
you
wouldn't
be
able
to
do
that.
With
this,
you
can
specify
your
own
predicate,
the
and,
and
similarly
we
do
the
same
for
the
the
property
name.
A
This
is
like
the
implementation
determining
it
doesn't
matter,
it's
more
like
a
like.
What
do
you
want
to
do
with
that?
So
so,
then
you
add
it
to
the
contract,
so
that
properties
is
a
properties,
is
basically
a
list
of
properties
you
have,
and
then
you
add
them.
So
I
think
it's
now
it's
kind
of
like
a
good
time
to
come
into
the
the
api
proposal.
So
the
the
main
piece
of
the
the
api
proposal
is
the
I
json
type
info
reserver.
A
So
this
thing
is
a
type
you
have
to
provide,
and
this
is
your
basic
resolver.
So
all
the
the
the
all
this
thing,
this
type
of
interface
does
is
given
a
type
you
provide
a
contract
and-
and
you
have
an
option
to
not
provide
it.
If
you
don't
provide
it,
it
will
throw
an
exception
and
the
specific
reason
for
this
design
choice
of
returning
new
label
in
here
is
also
conscious.
This
is
so
that
in
the
future,
we
can
provide
methods
like
combining
resolvers.
A
If
someone
wants
to
create
the
resolver
for
like
a
single
type
or
something
they
can
combine
multiple
of
them,
if
someone
returns
snore,
then
you
can
combine
them
into
one.
Currently,
we
didn't
include
that
as
part
of
the
api
review
process,
but
we
kind
of
are
thinking
forward
of
like
what
could
be
done
in
the
future
and
given
that
we
decided
like
okay,
this,
it's
probably
a
good
idea
to
make
this
knowable,
because
if
we
didn't
return
anything
we
threw
an
exception
or
something
then
combination
wouldn't
be
possible.
A
You
would
have
to
basically
know
what
the
given
resolver
does
in
order
to
know
if
it's
able
to
handle
something
or
not
so,
and
that
typing
for
resolver
is
part
of
the
json
serialization
options
so
that
you
can
obviously
get
and
set
the
type
in
for
resolver
here.
The
reason
these
guys
have
requires
a
reference
code,
which
is
the
linker
attribute
for
telling
you
how
I'm
doing
something
unsafe
is
because
we
need
to
provide
the
default
resolver,
which
is
using
reflection
here.
A
So
if
someone
didn't
set
it
at
all
and
you
would
call
gutter
you
would
you
would
be
doing
something
unsafe
by
using
the
the
reflection
based
resolver
like
if
you
use
a
setter
and
then
do
that,
it's
technically
not
unsafe,
you
will
still
get
a
linker
warning,
but
that
that
we
kind
of
think
is
the
like
a
best
best
experience.
Given
the
you
usually
don't
get
it
at
all
next
next
thing,
because
we
currently
have
a
json,
serializer
context
type,
which
currently
is
not
a
reason.
A
It's
not
resolver
per
per
current
definition,
but
it
meets
all
of
the
criteria
of
being
resolver.
So
we
decided
it
can
as
well
implement
I
json
typing
for
resolver,
so
this
is
a
type
used
for
by
the
source.
Gen
inside
of
the
system
takes
json
so
like
in
here
we're
doing
the
explicit
interface
implementation
is
because
it
I
believe
it
doesn't
have
options,
so
it
wouldn't
match
the
it
wouldn't
match
the
interface
we
have,
but
it's
pretty
close
it.
A
I
believe
it's
just
get
type
info
of
type
and
the
options
are
constructor
parameter
to
json
serializer
context.
So
this
is
the
reason
it
cannot.
It
cannot
ex
implicitly
implement
the
interface
so
another
pieces
of
the
puzzle
here
are
basically
the
default
json
typing
for
resolver.
It's
nothing!
It's
fancy.
It
has
just
like
literary
constructor
and
virtual
implementation
of
the
get
type
info
because
it
always
returns
the
answer.
It's
it's
not
nullable
answering
here.
A
So,
if
you're
like,
inheriting
from
the
default
default,
json
type
in,
for
example,
you
by
default,
will
not
be
able
to
define
benefit
from
the
future
kind
of
combination,
method
which
might
be
added
or
might
not
be
added,
but
at
least
in
the
closest
future,
but
like
if
you,
if
you
use
it,
you
know
that
you
will
get
something
usable
or
you
will
get
an
exception
in
the
worst
case.
A
So
the
the
use
case
is
simple,
so
so
currently
we
don't
have
any
methods
for
the
for
combining
resolvers.
So
it's
it's
not
part
of
this
api,
but
it
most
likely
will
be
added
in
the
future.
That's
my
my
guess.
By
the
user
scenarios
I
was
james
and
jeff
newton
king
kind
of
gave
us
in
the
in
the
chat
below
you
can
see
the
conversation
actually
in
this
specific
issue.
A
So
the
specific
example
is
like
that
that
a
library
might
provide
a
resolver
which
knows
how
to
handle
their
own
types,
and
you
might
want
to
combine
that
with
the
default
resolver.
Basically,
so,
if
that
guy
takes
precedence,
you'll
fall
back
to
the
default
default,
resolver
so
and
the
reason
for
what
you
might
want
to
do.
It
is
like,
if
you
have
like,
if
you
basically
don't
already
know
that
you're
not
gonna
use
from
other
other
people's
resolvers,
you
won't
be
combining
them,
but
basically
you
can.
A
C
A
A
It
doesn't
technically,
it
doesn't
need
to
be
true
that
doesn't
this
doesn't
individual
like
it's
still
going
to
be
possible
because
you
have
an
access
to
the
the
interface
and
you
can
could
make
it
a
field.
We
think
it's
basically
easier
to
to
just
override
it
like
in
many
cases,
and
because
this
is
this
method
is
called
literally
just
once
per
type
per
options
so
and
by
you're,
recommended
to
still
store
options
between
the
serialization.
A
Then
this,
like,
we
think
the
we
think
the
perf
in
this
specific
scenario,
doesn't
makes
much
of
the
difference
and
plus
comparing
to
what
this
thing
actually
does.
It's
literally
like.
Doesn't
it's
not
going
to
save
you
anything
by
not
not
having
by
not
having
this
virtual
so
which
one
is
just
a
computer.
D
D
You
know
someone
from
you
get
one
of
these
from
somewhere
else,
and
you
add
some
things
to
it
or
you
get
two
of
these
from
somewhere
else,
and
you
want
to
combine
them
in
various
ways
at
which
point
you
do
the
same
thing
with
the
default,
because
if
you
get
one
from
somewhere
else,
you're
not
gonna
be
able
to
override
what
it's
doing
so
you're
gonna
compose
and
you're
gonna
encapsulate,
and
you
know,
do
your
own
thing
and
then
delegate
to
it
or
whatever
so
creating
a
separate
way
to
do
it,
for
the
default
feels
a
little
bit
weird
like
if
you
notice
that
there
was
just
one
way
rather
than
one
way
unless
you're
dealing
with
the
defaults,
in
which
case
there's
another
way.
A
Fair
enough
so
yeah
so
like
like
they're,
like
actually
like
kind
of
two
scenarios
which
people
frequently
use
it.
So
one
is
when
they
construct
the
the
things
from
the
scratch
and
they
basically
provide
their
own
hierarchy.
So,
like
an
example
like
in
the
grpc
scenario,
you
know
basically
a
specific
set
of
types
you're
going
to
be
using
and
in
other
scenarios,
people
just
edit
like
a
single
type
like
modify
it
to
their
own
use.
A
D
A
A
D
A
So
because
I
I
we
don't
currently
have
any
the
proposed
combin
like
methods
for
combining
the
resolvers,
you
have
to
implement
your
online
class.
Basically,
every
time.
A
Maybe,
but
it's
also
it's
not
like
a
super
common
people.
Do
that,
like
we
feel
like
if
people
have
to
do
that,
they,
maybe
it's
it's
okay,
maybe
to
have
another
hoop
on
by
by
creating
their
own
class.
Like
sorry,.
D
A
This
is
not
about
polymorphism;
this
is
the.
This
is
the
customization
of
contracts.
A
Yep
so
yeah,
so,
okay,
so.
B
A
B
Sorry
to
interrupt,
just
as
I
put
it
in
chat
as
well,
but
basically
in
the
inheritance
pattern,
is
pretty
common
in
newtonsoft
in
eye
contract
resolver.
So
we
basically
just
emulated
that
to
make
it
easier
for
people
to
move
over,
it
seemed
like
a
straightforward
thing,
but
you
know
people
can
compose
any
way.
They
want
really.
A
A
We
can,
we
can
hear
you
and
yeah
go
ahead.
A
Yeah
so
they
answered
the
question.
Yes,
the
default
will
be
that
for
json
typing
for
resolver,
if
you
don't
specify
anything
and
unless
you're
in
the
source,
gen
mode,
then
this
json
serializer
context
will
be
your
resolver,
but
that
was
because
that
guy
is
actually
a
great
option.
I
believe
for
you,
I
and
we
cannot
hear
you,
but
I
know
you
said
something,
and
I
don't
know
what
that
was
so
now
is
your
time.
I
guess:
okay
I'll,
give
you
like
15
seconds
and
then.
G
A
Yeah,
that's
yeah.
B
Generally,
we,
there
are
many
composition
patterns
that
could
be
followed
here,
like
one
would
be
chaining,
which
would
work
as
you
described,
and
this
is
what
we
do
with
converters,
but
there's
also
like
different
forms
of
composition,
where
essentially
you're
calling
into
other
converters
and
making
modifications
on
the
result.
That's
also
a
very
valid
one
and
that's
like
the
primary
use
case,
we're
looking
at
catering
to
so.
A
There
is
some
comment
on
the
chat,
so
the
first
who
doesn't
return.
No
pattern
is
used
by
other
series
like
wcf
and
binary
formatter,
but
for
as
many
years
as
I've
been
looking
at
those
I've
never
heard
feedback
that
customers
preferred
one
pattern
over
another
yeah.
I
guess
it's
it's
a
matter
of
like
apples
versus
oranges.
A
So
that's
that's.
Why
we're
in
the
api
review?
Now,
I
guess
so,
let's,
let's
maybe
move
forward,
and
then
we
can
come
back
to
this
to
this
question
later.
A
So
let
me,
let
me
finish,
showing
all
of
the
possibilities
we
have
here
and
then
we
can
maybe
decide
on
why
one
way
or
another
of
doing
this
specific
thing
so
another
another
kind
of
major
point
here
is
the
json
type
info,
so
the
json
type
info
has
a
type
which
it's
assigned
to
so
like
once
you
construct
the
json
type
in
for
its.
It
has
a
one-to-one
mapping
with
the
specific
type
and
it
also
it's
also
tied
to
the
specific
options
and
the
converter
will
be
like
so
so.
A
The
converter,
which
options
decided
on,
will
be
also
accessible
by
the
converter
property
here.
A
So
the
user's
user
actually
cannot
change
this
this
on
the
json
type
info
and
then
the
kind
kind
thing
which
allows
you
to
tell
if
this
is
this
thing,
actually,
if
the,
if
the
properties
will
actually
be
used
or
not,
if
this
is
a
numerable
dictionary
or
like
a
custom,
converter
or
or
a
value
converter
and
some
of
some
other
type,
we
we
basically
cannot
change
other
things
than
like
number
handling,
maybe
so,
and
the
properties
which
is
ilist,
the
ilist
choice,
is
kind
of
here.
A
The
reason
which
is
I
list
here
is
so
that
you
can
specify
the
order
of
properties,
so
there
was
basically
two
design
choices
here,
either
put
order
on
the
json
property
info
or
and
make
this
I
collection
and
or
I
list
which
implies
the
order,
and
so
I
went
ahead
with
the
ilist
here,
which
made
more
sense
and
basically,
when
you
use
the
default
converter,
you
by
default,
we'll
get
this
sorted
by
the
order.
F
You
you
just
mentioned
json
metadata
kind
a
second
ago
yep,
so
jason
doesn't
differentiate
between
object
and
dictionary.
So
are
you
talking
when,
when
you
say
json
metadata
kind,
are
you
talking
about
like
the
on
wire
representation
or
the
dot
net
representation.
A
So
this
is
kind
of
a
bit
related
to
the
converter
and
their
implementation.
So,
basically,
if
this
is
set
to
object,
that
kind
of
implies
this
will
use
the
this
will
use
the
the
internal
object.
Converter
used
by.net
so
basically
like,
like,
I
was
kind
of
not
sure
if
to
add
this
at
all
into
the
adjacent
type
info.
A
Was
that
like,
if
you
add
properties
and
you're,
not
actually
an
object,
so
say
you're,
I
don't
know
like
your
json
type
info
of
integer
or
something-
and
you
add
properties
like
you
would
like
would
currently
throw
an
exception
because,
like
I
don't
know
what
to
do
with
the
properties
and
user
provided
them
so,
and
you
currently
don't
have
a
way
to
check.
If
you
are,
you
can
add
the
properties
or
not.
So
the
way
I
decided
to
that
was
to
to
provide
the
the
way
of
saying.
A
A
Like
how
do
you
call
it
it's
a
kind
of
metadata,
basically
like
we
serialized
so
like
like.
If
user
provides
their
own
custom
converter
and
like
we,
we
cannot
basically
tell
like
what
they
they're
gonna
write
to
json
so
like
they.
We
don't
know
what
they're
gonna
write
if
they're,
what
kind
of
tokens
they're
gonna
write
to
the
to
the
stream
like
so
like,
because
we
cannot
tell
that
that
basically
would
be
none
always
like
in
those
cases
but
for
objects
or
a
memorable
or
a
dictionary.
A
We
we
know
what
that
type
is
so
for
those
guys.
I
can
definitely
tell
okay
this
guy
is
this.
Guy
is
actually
serializing
dictionary,
so
possibly
in
the
future,
like
the
dictionary
will
also
be
allowed
to
to.
I
don't
know,
like
maybe
excellent
properties
with
this
guy.
Currently,
this
only
works
with
the
object
like
in
the
prototype.
Obviously
we
can.
We
can
redefine
that.
A
That
means
for
for
enumerables,
like
it's
also
like
kind
of
arguable,
like
perhaps
like
that
that's
one
of
the
design
changes,
we're
planning
to
think
of
in
the
future
is
like.
How
do
you
specify
the
element
converters
so
for
the
anova
and
dictionaries
that
would
apply
for
the
things
like
for
the
things
like
custom
converters
like
we
obviously
cannot
tell
like
what
the
user
wrote
in
their
custom
converter
like.
I
cannot
really
like
tell
if
they're
gonna
respect
the
settings
or
not,
so
I
like
it's.
A
Basically
those
cases
and
the
object
objects
could
also
be
extended,
something
like
object
with
parameterized
constructors.
So
this
is.
This
doesn't
refer
specifically
to,
like
a
specific
json,
token
token
type,
which
would
start
the
the
value
like.
So
it
doesn't
refer
to
the
like
array
in
the
array
or
or
an
object
in
the
json.
Specifically,
it's
it's
it's
more
like
a
internal
representation
of
of
the
specific
json
typing
for
token.
F
Yeah
yeah,
I
I
think
that
makes
sense
since
so
I
I
guess
my
follow-up
question
would
be
for
something
like
a
dictionary.
I
think
you
hinted
that
you
might
have
a
concept
of
like
overflow
properties
in
the
future,
which,
which
leads
to
kind
of
my
next
question.
You
have.
You
have
a
bunch
of
different
properties
on
json
type
info
number
handling
properties
create
objects.
Stuff
like
that
are,
are
all
of
those
properties
relevant
to
every
type
of
json
metadata
kind.
A
So
create
object,
yes,
it
is
properties.
It's
not
and
number
handling
is
like
if
you're
serializing
a
number
it
will
be
relevant,
otherwise
it
will
be
ignored,
always
and
others.
Basically,
there's
not
nothing
else
here.
So.
F
I
I
think,
maybe
maybe
something
that
would
be
useful
as
fleshing
out
the
usage
examples
that
you
had
earlier,
showing
how
each
of
these
four
different
types
might
be
consumed
I'll
yield
the
floor
now.
H
I
just
mentioned
that
in
search
generation
apis
we
have
some
different
sort
of
holder
types
that
contain
this
metadata
and
they're
different.
This
one
for
objects
are
different
for
collections,
so
might
be
worth
like
considering
like
splitting
these
apis
up,
or
I
just
wanted
to
mention
that
there's
something
between
searching
and
that
consideration
is
valid.
B
H
It
might
make
like
validation,
simple,
especially
if,
like
personal
stuff,
is
a
consideration
yeah.
We.
B
Do
do
that
for
search
10
for
what
it's
worth
we're
kind
of
constrained,
because
we
json
type
info
is
already
exposed
and
the
generic
json
type
info
of
t
is
already
exposed.
So
it
would
be
tricky
to
fit
all
these
things
into
the
existing
hierarchy.
But
for
what
it's
worth,
I
think
that's
a
good.
B
The
way
to
look
at
json
type
info
is
that
it
is
effectively
a
discriminated
union
between
three
kinds
of
converters
that
are
configurable
via
metadata
and
currently
the
only
one
that
is
specific
to
pocos
is
the
properties
list,
but
that's
just
a
subset
of
the
knobs
that
we'll
be
adding
to
this
thing.
So
having
a
tag
for
that
discriminated
union
kind
of
makes
sense,
I
not
necessarily
convinced
that
we
might
be
able
to
have
other
subtypes
to
json
type
info
for
these
specific
kinds.
B
A
Okay,
so
let's
continue,
maybe
so
so
one
of
the
kind
of
conventions
we've
done
here
is
if
something
is
normal
in
here,
that
means
there
is
most
likely
a
matching
property
in
the
jsons
in
example,
like
number
handling,
so
you
can
pro
provide
the
json
number
handy
attribute
on
the
on
the
specific
type
and
that
will
like
for
the
default
converter
that
will
actually
return
whatever
that
attribute
was
set
to
and
similarly
similar.
A
We
have
similar
thing
on
the
json
property
info,
which
I
will
go
into
future
in
that
in
the
future,
like
in
a
few
minutes.
Actually,
okay,
so
let's
finish
the
json
type
info,
so
there's
also
another
type
json
typing
for
of
t,
and
the
only
thing
which
this
differs
from
this
guy
is
that
you
can
provide
the
type
create
object
here,
and
the
value
of
that
is
basically
perf,
so
like
if,
like
internally.
A
You
can
create
an
object
without
going
back
and
forth
between,
like
basically
object
and
and
t
so
so
this
is
basically
just
perf
optimization
to
to
have
this
guy,
technically
speaking
like
we
could
make.
We
could
not
expose
it,
and
this
could
not
be
here,
but
then
the
the
first
surgeon
definitely
would
suffer
if
we
didn't
have
it
and
also
like
users
might
want
to
also
also
benefit
from
actually
having
this
as
well
on
their
like
in
their
in
their
implementation.
A
Like
you,
pretty
much
always
are
constrained
to
some
kind
of
tea,
and
in
many
cases
you
you
basically
know
what
the
t
is
and
like
you
just
want
to
use
it
so
and
if
you
don't
provide
it,
obviously
the
the
serialization,
the
serialization,
cannot
happen
because
we
don't
know
how
to
construct
the
specific
object,
so
the
the
properties
now
so
properties
are
bound
to
the
options.
So
the
options
are
there's
a
getter
for
the
options
here.
Also,
once
you
set
a
type
on
the
property,
you
cannot
change
it.
A
So
we
expose
this
type
through
this
property,
and
the
name
is
name
also
has
a
gathering
setter,
so
every
json
property
info
needs
a
name.
So
it's
also
part
of
the
static
construction
method.
I've
created
here
for
the
great
json
property
info,
so
it's
required
to
provide
a
name,
but
the
reason
this
also
has
a
setter
is
in
certain
scenario.
You
just
want
to
modify
the
existing
property
so
having
a
setter.
A
Having
setter
here
covers
the
scenario
where
you
want
to
like
an
example,
I
don't
know
like
maybe
prefix,
every
property
with
something
on
or
something
something
along
the
lines.
Basically,
like
I
don't
know
what
users
might
want
to
do.
Specifically.
We
currently
also
have
json
naming
policy,
which
you
can
already
do
most
of
the
stuff
with
that,
so
so
yeah
technically
technically,
it
could
maybe
get
away
with
not
having
this,
but
that's
kind
of
like
in.
A
In
my
opinion,
it
makes
it
easier
to
expose
it
because
the
contract
is
basically
like
a
manifestation
of
like
all
of
the
knobs
we
have
elsewhere
and
like
it
is
basically
instantiates
all
of
these
options
we
created
before
and
now
you
can
adjust
the
knobs
basically
further.
If
you
wanted,
and
and
otherwise
like
you,
you
don't
touch
the
the
contracts.
A
Okay,
another
another
thing
I
think
here
is
the
custom
converter,
which
I
I
don't
know
it
doesn't
have
a
set
here.
It
should
have-
I
I
guess,
that's
overlooked,
so
so
you
know
it
should
have
saturday,
I
think
which
happened,
because
we
renamed
it
last
minute
and
probably
disappeared
along
the
way
anyway.
So
the
custom
converter.
A
The
reason
this
this
has
a
custom
custom
prefix
in
here
is
because
it
can
be
said
to
know,
and
the
null
means
here,
that
this
will
be
deducted
from
type
and
the
options
will
the
construct
construct,
the
converter
for
you,
whatever
the
default
is
for
for
the
specific
type.
If
you
override
it,
then
the
specific
property
will
use
the
this
custom
converter.
So
you
can,
you
can
do
the
customization
for
the
specific
property
here
and,
and
also
the
non-generic
version
of
the
adjacent
property
info
has
a
gathering
setter.
A
If
you
look
at
the
typed
one,
so
the
generic
version,
this
will
be
this
will
this
will
have
a
specific
t
on
the
on
the
getter
and
setter.
So
this
is
also
perfect
optimization,
so
these
guys
will
actually
internally
cost
to
this
guy,
if,
if
you
provide
them
so
because
also
internally,
every
json
property
info
will
be
json
property
info
of
t.
So
so
those
guys
will
be
translated
into
into
the
typed
version.
So
this
will
be
slower
if
you
go
directly,
but
this
is
a
convenience.
A
A
So
those
those
specifically
untyped
versions
are
kind
of
optional,
but
it
makes
it
for
completeness
it
kind
of
makes
sense
to
add
them.
In
my
opinion,
at
least
it's
it's
because
in
many
cases
you
you
don't
care
about
perf
that
much
to,
and
you
care
more
about
the
flexibility
of
having
this,
because
in
order
to
create
the
json
property
type
in
50,
you
have
to
call
them
a
generic
like.
A
If
you
have
like
an
example
like
in
the
grpc
scenario,
you
you
kind
of
have
a
list
of
all
of
the
possible
types
and
their
and
their
gutters
and
setters.
So
in
those
in
the
specific
case
like
basically
in
order
to
to
call
into
the
that
typed
json
property
info
of
t
you
have
to.
A
You
have
to
use
the
reflection
essentially
to
call
calling
to
some
of
those
apis
so
but
like
doing
that
also
gives
you
a
perf
benefit
of
this
being
faster,
and
if
you
don't
do
that
and
you
use
the
generic
like
non-generic
apis,
it's
still
possible.
But
if
it
moves
lower
in
in
cases
of
structs,
it
will
actually
do
lots
of
boxing
and
in
certain
scenarios
it
will
be
actually
pretty
slow.
A
And
this
was
actually
a
specific
request
to
have
a
to
have
a
typed
version
of
getters
and
setter.
A
Setters,
not
that
that's
actually
coming
from
this
new
things,
like
my
initial
kind
of
pre-review,
actually
didn't
have
the
the
typed
version
at
all,
but
but
james
actually
mentioned
that
it's
a
common
scenario
where
you
want
to
avoid
boxing-
and
we
want
to
have
this
actually
be
a
be
a
first
class
scenario
and
the
the
non-gendering
version
be
a
second-class
citizen,
because
if
it's
already
slower,
it
might
as
well
as
well
be
slightly
more
slower
and
another.
A
Another
method
here
is
the
concealer:
it's
the
same
with
the
for
the
type
and
untyped
version.
So
this
basically
depending
on
the
specific
value
of
the
property,
you
can
decide
if
that
specific
property
will
show
up
in
in
the
serialized
form
or
not.
And
another
thing
here
is
the
number
handling
as
well.
This
is
the
same
not
as
was
in
the
adjacent
type
info,
and
it
also
matches
the
attribute
behavior.
So
by
default
you
will
get
whatever
the
value
you
put
on
the
attribute
here.
A
So
yes,
this
is
actually
a
good
question,
so
this
is
a
dual
dual
mode.
So,
basically,
at
the
type
of
the
at
the
moment,
when
you're
constructing
contract
it
you
can
modify
them
for,
like
whatever,
whatever
has
a
setter,
it's
modifiable
but
like
after
you,
it's
used
on
on
the
first
serialization
or
the
serialization.
Those
options
are
locked
and
the
type
becomes
immutable
and
if
you
try
to
to
set
it
or
something
it
will
throw.
I
A
But
the
entire
options
become
submittable.
I
believe
it's
currently
the
case.
I
don't
know
if
you've
covered
all
the
cases,
but
that's
the
intention
at
least
that
the
options
becomes
immutable
after
the
first
usage,
and
that
includes
all
of
the
json
typing.
First,
the
the
contract
resolver
generated.
I
A
So
yes,
each
json
type
info
is
specific
to
options,
so
each
options
will
have
separate
json
type
info,
because
each
option
can
have
different
resolver
and
the
different
different
options
might
because
they
provide
a
different
resolver.
They
might
generate
different
type
info
for
for
the
same
options
and
for
the
specific
type.
A
I
A
Yes,
the
I
mean
the
json
type
info
is
kind
of
like
constructed
on
on
demand.
So
basically,
whenever
the
first
first
time,
the
type
specific
type
is
used,
the
resolver
will
construct
the
construct,
the
specific
json
type
info,
and
at
that
point
it's
also
locked
because
it's
also
used
at
the
same
time,
because
that
happens
during
the
deciarization.
A
But
it
technically
could
pre-generate
the
json
type
in
for
before
then
you
return
the
specific
instance
in
your
resolver,
but
it
will
also
become
locked
after
the
first
user
so
like
actually,
actually
that
happens
in
the
case
of
the
sergeant,
so
that
actually
generates
a
bunch
of
properties
which
are
using
typing
first,
and
in
those
case
you
can
also.
They
are
also
modifiable
in
a
sense
until
the
first
usage.
I
And
then
so
the
other
question
is
you
basically
propose
that
we
have
both
the
generic
and
the
non-generic
set,
get
methods?
So
what
happens
if
I
set
one
or
the
other
is
basically
when
I
said
the
generic
one?
Is
the
non-generic
one
also
initialized
or
is
the
idea
whatever
is
non
like?
If
did
not,
if
the
generic
one
is
not
now,
we
use
it,
regardless
of
whether
a
non-generic
one
is
specified.
A
So
the
source
of
is
always
the
this
guy,
so
this
guy
will
always
be
set.
So
no
sorry,
not
the
the
typed
one,
and
this
guy
will
always
produce
the
so
the
non
non
non-generic
version
will
always
kind
of
construct
a
new
new
new
rapper,
basically
around
it
like
it
might
there
might
be
some
caching
happening
in
and
stuff
like
that
searching
is
the
same
instance,
but
in
general,
like
this
is
a
source
of
truth.
I
I
Okay,
so
basically
it
doesn't
matter
which
one
I
said,
the
other
one
will
always
be
in
sync
but
correct,
correct,
okay,
so
that
makes
sense.
Then
the
other
question
I
have
is
that
you
call
these
things
can
serialize,
but,
based
on
your
comment,
it
seems
more
like
should
serialize
might
be
a
better
name.
A
Yeah,
I
mean
actually
yes,
yes,
I
agree.
Maybe
maybe
it's
a
better
name.
A
I
A
I
I
just
have
my
own
notes
on
the
side
by
the
way
you're
right
I
should
probably
I
should
probably
capture
them
so
yeah.
Let
me
write
this
up.
Yeah
everything
you
said
makes
sense
to
me.
The
only
thing
I'm
still
not
entirely
sure
about
is
kind
of
the.
I
I
think
eric
explained
this,
that
the
user
may
want
to
kind
of
modify
or
adapt
a
json
property
or
adjacent
type
info,
which
is
where
you
think
this.
You
know
this
converter
style
approach
where
you
register
multiple
may
not
work.
It
seems
like
that's
also
what
jason.net
has
been
doing,
where
there's
only
one
contract
resolver
that
you
basically
have
to
override
and
then
you
know
basically
delegate
to
other
instances,
but
I
I
I
guess,
I'm
my
imagination
isn't
strong
enough.
I
A
So,
yes,
I
I
think
like
actually
james,
like
if
you
scroll
down
here,
we
actually
have
this
specific
conversation
about
this.
So
specific
specific
example
here
is
like
an
example,
the
unhibernate
and
f
sharp
resolver
might
have
their
own
resolvers
and
then
and
then
basically,
this
is
actually
the
the
specific
design
conversation
we've
had.
A
Yes,
so
so,
basically
yeah
like
we,
we
are
not
strongly
like
are
in
one
camp
or
another
in
in
terms
of
like,
like
which
design
is
better,
it's
still
like
apple
center
and
just
like
which,
like
whoever
prefers
one
or
another,
and
that's
why
we're
kind
of
talking
now
now
in
the
api
reviews
to
decide
which
apple
is
better.
I
guess.
A
Yep,
so
so
having
the
having
having
the
basically
the
interface
which
returns
new
label
like
allows
you
to
create
any
possible
pattern,
you
can
possibly
think
of
while
going
with
this
one
specific
approach
like
we
are
not
100
convinced.
A
That's
the
case
that
that
was
the
the
consensus,
I
guess,
but
like
maybe
maybe
the
the
pattern
of
like
because,
like
there
are
a
couple
of
scenarios,
an
example
say
someone
created
a
default
resolver
and
then
they
want
and
hibernate
to
take
precedence
over
the
default
one
because,
like
in
the
in
the
specific
case,
if
you
add
an
hibernate
resolver
later,
then
you
would
have
to
basically
prepend
it
to
the
list,
because
otherwise
default
converter
will
always
return
the
the
answer
which
is
non-null,
and
in
that
case
you
will
never
actually
get
anything.
A
So
you
also
always
have
to
prepend
it
on
the
list
so
and,
and
that
basically
creates
like
a
really
starts,
basically
kind
of
being
a
bit
ugly,
maybe
like.
Maybe
the
list
should
be
considered
like
from
the
back
to
to
the
front,
maybe
like
and
then
basically
starts
being
like
really
vague
on
on
what
the
ordering
should
be
like,
while,
if
you
make
it
an
interface,
this
is
like
very
explicit,
like
okay,
now
user
basically
decides
which
way
it
goes.
A
A
Okay,
now
this
takes
precedence
over
and
hibernate,
and
the
spread
takes
precedence
over
the
default
json
typing
for
resolver,
while
in
the
other
case
in
case
of
a
list,
you
kind
of
I
mean
it's
kind
of
the
same
problem,
but
still
the
list
will
pretty
much
very
frequently
would
have
to
be
like
very
intentionally
intentionally
kind
of
created,
while
the
combination
pattern,
knowledge,
okay,
I
can
now
wrap
and
prepend
very
cheaply
because,
because
like
if
you
create
a
combinator,
you
can
you
can.
A
You
know
imagine
like
a
simple
implementation
which
implements
the
adjacent
type
for
resolver,
takes
basically
two
implementations
and
combines
left
the
right
one
and
and
then
you
can
prepare
very
cheaply
with
that
kind
of
case.
Like
a
three
three
pattern,
I
guess,
but
the
list
is
kind
of
I
mean
it
will
also
work,
but
you
know
you
would
have
to
know,
know
upfront
all
of
the
possible
options
here
and
I
think
james
even
mentioned
one
of
the
options
where
you
don't
have
control
like
which
one
takes
precedence
like.
A
I
think
I
can't
remember
where
that
specific
example
was,
but
he
showed
basically
the
example.
I
think
in
the
asp.net,
where,
where
you
get
that
options
instance
in
one
of
the
callbacks
and
then
you
basic,
you
can
modify
it
in
in
one
specific
place.
I
cannot
remember
where
that
oh
yeah,
I
think
it
was
specifically
this
example.
A
So
so
basically
he
has
access
to
the
typing
for
resolver
the
existing
typing,
for
example.
Now
you
know
like
if
we,
the
technical,
if
we
didn't
expose
the
the
exposed
this
option,
and
this
would
be
a
list
and
maybe
we
should
allow
cheap,
prep
and
prepending
and
appending,
then
maybe
maybe
that
would
be
better
but
like
yes,
we
we
were
not
hundred
percent
convinced
in
either
way
and
like
we
think
the
the
just
exposing
the
the
interface
directly.
That
gives
you
kind
of
the
most
flexibility
of
our
words.
I
A
B
In
mind
is
that
we're
retrofitting
the
contract
resolver
on
top
of
the
json
serializer
context,
which
is
a
source
gen
specific
thing
and
the
way
that
works
currently
is
that
it
assumes
a
single
json,
serializer
options.
Instance.
Sorry,
a
single
json,
serializer
context,
impedance
per
options
instance,
and
there
had
been
discussions
like
lyomi-
was
pointing
this
out
that
we
we
might
want
to
consider,
offering
support
to
users
to
combine
serialization
contracts
from
multiple
contexts,
and
I
I
think
that
kind
of
fits
into
the
same
problem.
B
But
I
still
think
that
this
should
be
in
principle
solvable
via
combinators,
rather
than
having
like
a
first
class
list
representation
because,
as
I
pointed
out,
not
all
composition
patterns
are
compatible
with
having
a
list
like
when
you
want
to
compose
and
mutate
that
actually
kind
of
falls
apart.
Yes,.
A
Like
example,
scenario
of
what
I
just
mentioned,
so
it
will
be
say
you
have
two
classes
generated
from
surge
gen
and
you
might
want
to
pick
like
a
couple
of
types
from
one
and
a
couple
of
from
the
other
and
like
now
you're
in
the
basically
stuck
because
the
list
doesn't
work.
B
And
if
you
look
at
the
the
top
post
in
in
your
screen
right
now,
like
I
kind
of
sketched
a
couple
of
combinators
that
offer
like
common
composition
patterns,
one
using
callbacks
and
one
using
chaining
in
principle,
both
would
be
implementable
using
user
code.
But
the
question
is:
would
we
want
to
offer
these
out
of
the
box
or
something
like
that
out
of
the
box.
I
B
Apparently,
there's
a
one-to-one
mapping
between
options
and
contexts
and
we
were
discussing
possibly
extending
that
and
actually
this
feature
would
unlock
composing,
multiple
adjacent,
serializer
context,
generations.
So.
H
I
Agree
below
me,
because,
logically,
you
you
serialize
right
and
doing
that
civilization
operation.
You
have
to
agree
what
your
universe
is
right
and
so
there's
maybe
there's
a
meta
universe
that
aggregates
universities
right
but,
like
logically,
there
has
to
be
one
right
for
a
given
type.
You
have
to
decide
what
resolver
to
use
right.
I.
B
Mean
what
one
use
case
I
can
think
of
is
consider
you're
consuming
a
nougat
package
that
already
has
source
generated
contracts
for
a
set
of
types
that
it
exposes,
and
you
want
to
con
consume
these
and
combine
them
with
certain
pocos
that
you're
interested
in,
for
example,
like
envelope
classes.
Currently,
there's
no
way
to
do
this
other
than
falling
back
to
reflection
for
your
types.
So
I
think
it's
I
think
it's
conceivable
and
it's
I
I
don't
think,
there's
anything
inconsistent
about
it
to
just
compose
multiple
sources
for
metadata.
I
Yeah
but
basically
you're
proposing,
then
you
have
a
context
that
allows
you
somehow
to
aggregate
multiple
other
contexts,
but
then,
at
the
end
of
the
day,
you
get
one
context
out
that
you
can
pass
to
serialize
right.
You
never
have
a
case
where
you
would
say
serialize
with
an
eye
new
model
of
context
or
something
right
because
well
what
would
that
even
mean
right?
Well.
B
In
this
proposal,
you
you
don't
actually
have
any
json
serializer
contacts
that
are
aggregates,
but
you
have
in
the
the
I
json
type
resolver
that
could
act
as
an
aggregate
right.
I
I
A
B
Would
say
we
should
not
do
this
by
default
using
magic.
We
should
just
if
users
want
to
compose,
we
give
them
the
interface,
and
you
know
let
them
go
nuts.
I
Let's
say
the
azure
sdk
is
somehow
figure
out
how
their
types
and
their
sdk
types
are
both
basically
being
resolved
right
so
like
I
think
there
needs
to
be
a
you
know,
a
somewhat
default
answer
for
how
you
normally
compose
across
multiple
nuget
packages
with
their
own
contracts
right,
and
I
think
to
me
it's
reasonable
to
say
we
have.
You
know
some
sort
of
default
things
I
mean
what
you
have
on
screen
right
now
looks
pretty
powerful
and
then
the
rest
is
just
well.
I
You
implement
your
own
adjacent
type
resolver
and
you
write
the
switch
or,
if
statement
in
there
yourself,
but
we
have
pretty
common
patterns
that
will
generally
accommodate
you
know
99
percentile.
Maybe
what
you
have
on
screen
is
already
more
than
we
need,
but
I
think
I
think
we
would
want
something
very
simple
that
you
know.
B
Yeah,
I
agree
that
we
need
to
have
like
a
best
practices,
documentation
explaining
how
you
do
this
kind
of
thing,
like
one
example,
I
can
think
is
like
mixing
and
matching
three
different
json
serializer
contexts
and
then
doing
a
bit
of
reflection,
based,
f,
sharp
contract
resolution,
and
then
you
know,
mix
in
a
bit
of
an
hibernate
like.
B
What's
the
best
way
to
do
this,
the
answer
there
is
no
best
way
you're,
but
no
we're
not
gonna
write
that,
but
I
guess
I'm
saying
there
might
be
a
way
to
do
this
for
same
scenario.
If
that
makes
sense.
I
A
Well,
sometimes,
you
cannot
add
attributes
to
something
which
already
shipped
elsewhere
right
like
in
certain
scenarios
like
you,
have
a
nugget
package,
you're
stuck
with
it
and
you
don't
have
any
other
options.
So
it's
an
alternative
way
to
provide
it.
In
some
cases,
people
don't
want
to
pollute
their
code
for
various
reasons,
and
so
yes.
B
Basically,
when
you're
using
newtonsoft,
actually
extending
the
contract,
resolver
is
pretty
standard
like,
for
example,
you
extend
the
contract
resolver
to
do
like
camel
case
property
naming
which
we
have
like
a
separate
feature.
That
does
that
already.
So
I
think
users
are
kind
of
I
I
think
they're
familiar
with
with
this
with
this
abstraction
and
I
think
they'll
be
able
to
to
get
things
done
done
with
it.
Yeah.
A
I
It
seems
more
common,
it's
possible
that
in
system
text.json
is
less
common,
because
some
stuff
is
already
built
in,
like
the
casing,
for
example,
that
people
don't
have
to
do
it
as
often,
but
it
seems
to
me
we
should
just
some
api
evolution
standpoint.
Also,
it
kind
of
makes
me
nervous
to
say
we
have
this.
You
know
mythical
combinator
feature
that
we
haven't
really
designed
yet
and
we
think
it
will
solve
everything,
but
then,
when
we
actually
try
to
edit
it
might
be
difficult.
I
B
Yeah,
I
I
wouldn't
mind,
including
something
like
that,
just
to
just
to
give
us
the
opportunity
to
test
the
design
yeah.
I
Because
I
mean
that's
really
where
you
find
out,
I
think
you
have
to
implement
a
few
of
them
to
actually
see
you
know
how
you
can
delegate-
and
you
know
whether
you
have
the
right
kind
of
patterns
on
the
type
in
the
right
shape
to
do
that
and
some
stuff
might
be
difficult
to
change
data
right.
H
There's
something
I'm
curious
about
like:
does
the
untyped
like
the
untyped,
getters
and
setters
on
jason,
provide
info
have
any
like
polymorphism
considerations?
You
need
to
be
careful
about.
B
Is
no
matching
typed
version
yeah
now
the
the
t
type
in
the
getters
and
setters
that
shouldn't
be
an
issue,
because
if
the
declare
type
is
t
for
the
property,
then
whatever
the
runtime
type
is,
it
should
still
be
assignable
to
t.
B
Sounds
good,
thank
you.
I
I
mean
I
I
might
want
to
raise
an
open
design
question
for
jason
property
info
of
t,
and
I
I
have
shared
this
already
with
with
kristoff,
but
I
I
will
say
that
the
json
property
info
of
t
strikes
me
as
odd,
because
I
don't
necessarily
you
know
when
looking
at
the
type,
I'm
not
necessarily
sure
whether
the
t
type
corresponds
to
the
declaring
type
or
the
property
type.
Now.
B
That
being
said,
this
actually
reflects
how
the
internal
implementation
is
currently
using.
Getters
and
setters,
like
the
the
declaring
type
is
boxed
and
the
property
type
is
strongly
typed,
and
there
are
reasons
for
that
like,
for
example,
it
enables
setters
for
structs
actually
working,
but
I
guess
my
question
is
and
and
christoph
mentioned,
that
james
has
a
use
case
for
this,
but
I'm
wondering
should
we
like?
Do
we
actually
need
a
generic
json
property
info
of
t?
Could
we
on
as
a
for
the
mvp?
H
B
F
H
B
Yeah,
I
think
that's
no
longer
the
case
like
actually
now.
That's
it
actually
fully
matches
the
declaring
type
of
the
property
like
that.
That's
been
changed
in
in
seven
I
mean.
A
I
mean
you
know
it
technically
doesn't
have
to
exist,
but,
as
I
mentioned,
that
was
one
of
the
requests
we
got
from
the
from
james
to
and
I.
A
B
Yeah,
I
mean
sure
you
might
end
up
boxing
a
few
integers
when
you're
getting
and
setting
them.
I'm
not
necessarily
sure
that
this
would
substantially
contribute
to
the
performance
of
serialization
overall.
B
But
my
my
the
reason
why
I'm
bringing
this
up
is-
and
I
did
bring
it
up
in
the
in
the
comments
is,
should
we
look
at
in
the
future
exposing
js
property
info,
that
is
generic
both
on
the
declaring
type
and
the
property
type,
and
as
such,
have
like
a
func
from
t
declaring
type
to
t
property
type,
obviously,
with
the
understanding
that
this
would
be
complicated
to
get
right
for
structs.
In
the
setter
case,
we
had
a
similar
notion.
H
Back
in
3-0,
but
then
the
implementation-
I
don't
remember
the
details,
but
the
implementation
wasn't
very
didn't
work
well
with
some
some
platforms
like
xamarin
and
android.
So
I
know
steve
spent
a
lot
of
time
refactoring
to
simplify
this,
to
have
a
single
t
and
a
lot
of
those
problems
run
like
disappeared.
So
I
mean
I'll
just
like
verify
that
we're
running
know
tests
on
all
those
platforms.
Well,.
A
B
But
the
shutter
is
basically
really
easy
to
get
wrong.
If,
if
you
scroll
down
to
one
of
my
comments
like
actually
to
get
the
setter
to
work
in
this
example,
you
actually
need
to
perform
an
unsafe
unbox.
So
it
works
technically.
But
you
know
it
is
a.
It
is
introducing
a
foot
gun
for
users
that
you
know
might
just
want
to
set
a.
B
Yeah,
so
this
is
basically
how
source
gen
implements
setters
at
the
moment,
using
the
current
api
shape,
so
we're
essentially
making
this
the
default
way
of
expressing
setters
given
the
api
and
for
what
it's
worth.
That's
also
true
for
the
box
variant.
Unless
you
do
a
reflection
based
set.
I
A
Yeah
and
if
the
t
was
t
was
generic,
then
you
would
always
get
a
copy,
basically,
because
there.
I
I
B
Because
internally,
yeah
we're
definitely
taking
care
that
this
doesn't
happen.
I
mean
structuralization
is
working
and
system
texture
isn't
lost
to
magic.
But
the
thing
is
my
concern
is
that
we
might
be
pushing
that
responsibility
off
to
the
user
and
that
kind
of
makes
me
worry
about
the
design
like
sure
internally.
It
works
fine
if
you're,
careful
but
there's
an
element
of
unsafeness
here.
B
That
makes
me
think
that,
should
we
just
expose
the
untyped
variants
and
say
you
know
just
use
propertyinfo.set
value
on
the
box
things
and
have
it
work
as
expected,
and
perhaps
we
might
consider
a
a
different
design
in
future
releases.
B
Only
have
the
untyped
ones
for
now
and
in
the
future,
like
one
possible
solution
is
like
if
you
look
at
the
very
last
line
in
christoph
screen,
there's
an
alternative
way
of
declaring
a
setter,
for
example,
where
you
always
need
to
return
the
value
of
the
struct.
Of
course
that's
not
optimal,
but
that's
one
possible
design
and
there's
a
few
more
like
you
can
use
special
delegates
that
accept
ref
parameters.
B
So
if
you
scroll
down
christoph
just
a
bit,
you
would
you
might
be
able
to
define
a
setter
that
accepts
the
declaring
type
by
ref
and
that
should
you
should
be
able
to
define
a
setter
that
works
as
expected.
But
again
this
is
kind
of
open
design
space.
I
don't
think
we
should
try
to
make
any
decision
here,
which
again
makes
me
think
that
maybe
we
should
refrain
from
taking
action
on
the
generic
json
property
info
apis
in
general
and
just
use
the
untyped
ones.
For
now,.
I
I
B
Isn't
it
it
doesn't,
but
the
untyped
version
kind
of
emphasizes
that
you
know
you
the
only
way
you
can
do
this
is
by
using
reflection
based
setting.
So
you
either
do
a
field
info
dot,
set
value
or
proper
property
info
dot
set
value
having
something
that
is
generic
for
quote
performance
means
that
people
might
assume
that,
oh
I'm
just
going
to
use
it
like
doing
a
normal
property
set.
Only
that
doesn't
actually
work
as
expected
for
structs.
I
B
I
B
B
B
I
guess
I'm
saying
that
just
just
surfacing
the
untyped
json
property
info
type,
that
has
that
exposes
getters
and
setters
in
the
dum-dum
way
of
you,
know,
taking
a
couple
of
objects
and
returning
void.
That
kind
of
emphasizes
the
fact
that
you
know
you're
better
off
using
reflection
for
this
one
and
really.
A
Honestly,
like
the
way
I'm
looking
at
this,
it's
it's
really
an
advanced
feature
and
using
the
the
setters
is
even
more
advanced
because,
like
normally
people
would
probably
just
edit-
and
you
know
like
like
in
an
entire
jrpc
scenario
like
james-
actually
never
uses
any
even
a
single
struct.
So
he
didn't
even
have
this
problem,
so
I'm
kind
of
makes
me
think
like
if
that
one
percent
or
less
of
the
users
who
would
even
use
this
feature,
like
would
have
this
problem.
They
would
basically
immediately
find
an
answer
somewhere
like.
I
A
I
mean
to
me
this
specific
design
using
the
ref
of
the
td.
Declaring
type
would
make
the
reference
types,
the
experience
for
the
reference
types
weird,
and
but
it
would
make
the
distracts-
I
guess
normal,
but
like
yeah
like
I
guess,
either
the
reference
types
will
suffer
or
the
structure
will
suffer
like
you
know.
We
have
to
pick
pick
one
way
or
one
word
or
another
and
like
I
I
guess
we
are
now
consistent
with
the
what
the
reflection
is
doing
like
if
we
stay
with
the
current
design.
B
B
B
I
I
guess
another
way
of
looking
at
this
is:
do
we
have
benchmark
numbers
saying
that
actually,
when
we
use
the
strongly
typed
getters
and
setters,
we
got
like
a
10
performance
improvement.
I
don't
know.
A
I
I
kind
of
trusted
james's
judgment
here.
That
was
that's
going
to
be
my
answer
here.
I
I
B
That's
a
good
question
in
the
case
of
source
gen,
the
the
getters
and
setters
have
the
exact
same
signature
as
the
generic
json
property
info.
However,
it
is
not
expected
of
users
to
actually
consume
these
apis.
These
apis
are
consumed
by
the
c-sharp
code
that
we
generate
in
the
first
place.
So
there's
no
foot
gun
as
such
to
be
considered
in
the
case
of
searching
in
the
case
of
users,
arbitrary
calling
into
getter
and
center
apis.
That's
a
different
story.
I
B
You
might
be
able
to
compose
it
any
way
you
like
in
in
the
sense
that
jason
serializer
context
is
an
instance
of
a
resolver
that
returns
a
nullable
result,
because
it,
it
obviously
hasn't
generated
metadata
for
every
single
typing.net.
B
So
it's
basically
up
to
you
to
decide
whether
you
want
to
chain
multiple
instances,
implementations
of
the
interface,
be
be
it
instances
of
gesturalizer
context
or
be
it
reflection,
based
stuff
that
mutate
metadata
like
I.
I
don't
think
there
is
one
true
way
of
doing
it.
If,
if
that
answers
your
question.
B
I
Then
I
write
my
own
with
whatever
I
mean.
Basically,
I
just
either
extend
the
default
json
type
in
for
resolver
or
just
implement
my
own
interface
myself,
and
then
I
choose
to
delegate
to
the
json
sql
as
a
context,
one
that
I
got
generated
or
I
have
my
own
things
on
top
and
then
when
I
actually
serialize,
I
presumably
set
the
yeah.
B
So
in
in
source
gen,
what
happens
is
there's
this
private
field
that
is
currently
not
setable
from
the
outside,
it's
being
set
by
the
json
serializer
context
itself,
and,
and
that
is
that
that
is
creating
a
one-to-one
coupling
between
adjacent
serializer
options
instance
and
a
json
serializer
context,
instance,
and
that
cannot
be
changed
now.
The
change
that
this
feature
will
bring
is
that
it
replaces
this
field
that
is
currently
of
type
gesturalizer
context,
with
a
publicly
settable
property
that
is
of
the
interface
type.
B
So
the
existing
source
gen
scenario
would
work
by
setting
assigning
that
interface
property
to
that,
whatever
j
serializer
context,
we're
passing.
I
B
So
so
the
way
that
you
do
this
in
searching
is
that
essentially,
your
generated
json
serializer
context
will
create
an
options
instance
for
you
that
you
can
use
to
pass
into
the
different
apis,
although
that's
not
the
standard
way
of
doing
it,
and
that
will
make
sure
that
it
is
assigned
the
right
context.
B
Instance
for
resolving
the
metadata
and-
and
that
is
a
special
case
of
what
is
being
proposed
here,
where
you
have
a
a
general
purpose-
property
that
you
can
use
to
assign
arbitrary
metadata
resolvers
now
for
for
source
gen.
For
for
the
sourcing
case,
I'm
assuming
that
what
what
is
going
to
happen
is
that
we're
going
to
lock
the
options
instance
that
has
been
generated
that
has
been
instantiated
in
the
context
of
a
generated,
json,
json,
serializer
context
instance.
I
B
So
so,
basically,
I
think
the
main
the
main
way
to
look
at
this
is
that
json
serializer
options
that
are
instantiated
within
the
context
of
adjacent
serializer
context
are
locked
to
that
resolver
and
any
attempts
to
overwrite.
That
would
probably
result
in
invalid
operation
exception,
because
the
json
serializer
options
would
be
locked,
but
for
other
things,
other
json
serializer
options,
instances
that
you
create
via
the
existing
constructor.
You
should
be
able
to
assign
any
type
of
resolver.
B
Be
it
a
context,
be
it
a
combinator
that
combines
like
50
different
contexts
in
you
know.
You
know
in
in
a
chaining
way
or
in
a
mutating
way
or
whatever
you
like.
B
Are
constructor
so
so
if
you
scroll
down
christoph,
if
you
scroll
down
to
the
examples.
B
Yeah,
so
when
you
create
adjacent
serializer
options
by
calling
into
its
default
constructor,
then
you
should
be
able
to
set
a
typing
for
resolver
using
your
custom
resolver.
Now,
if
you
get
the
options
from
a
generated,
json,
serializer
context,
the
typing
for
resolver
should
already
be
populated,
and
it
should
contain
an
instance
of
that
json
serializer
context.
I
Yeah,
I
guess
that
is
kind
of
what
I
was
saying
like
my
recollection
or
maybe
that's
wrong,
but
like
wasn't
the
idea
that,
if
I
want
to
use
you
know
source
generated
stuff,
then
I'm
not
using
the
apis
to
take
options.
I
take
the
api.
I
use
the
apis
to
take
the
context.
A
F
A
Will
assign
the
context
to
itself
and
the
context
will
assign
options
like
basically,
they
create
one
one
to
one
mapping.
A
Don't
don't
ask
me
about
the
why
I
I
can
tell
you:
what's
in
the
code.
H
The
search
engine
will
generate
a
context
and
then
the
context
will
return
typing
for
instances,
and
I
think
it's
at
that
layer
that
user
wants
their
users
might
want
to
make
changes
like.
So
we
give
you
like
a
typing
folder
that
has
a
list
of
properties
and
all
those
type
of
things,
and
then
you
want
to
modify
that
list,
so
it
sort
of
works
in
the
same
way.
B
I
Basically
so-
and
maybe
this
is
old
guidance
based
on
where
we
so
I
think
originally,
we
didn't
have
this
mapping
right
this
b,
directional
mapping
between
the
context
and
the
options.
So
if
you
wanted
to
use
the
source
generated
once
you
had
to
use
the
serializer
option,
the
serialized
methods
that
take
the
context
rather
than
the
options
right,
and
so
my
question
was,
if
I
want
to
do
that,
but
I
also
want
to
inject
some
somehow
my
own
contract.
What
would
I
do
and
it
sounds
like
what
you're
saying
is?
I
Well,
you
can't
use
the
one
that
takes
the
context.
You
have
to
use
the
one
that
takes
the
options
construct.
The
options
yourself
set,
the
type
result
to
whatever
you
want
it
to
be,
and
then
that's
that's
the
outcome
of
that
and
that's
why
I
was
asking:
how
does
this
compose
with
source
generation
because
it
sounds
like
it
is
not
so.
B
So
I
I
trying
to
answer
your
question.
The
main
the
main
methods
that
are
used,
like
I
think
the
the
recommended
methods
for
doing
source
generation
currently
are
the
overloads
that
accept
json
type
info
of
t
as
the
parameter,
because
they
also
avoid
the
whole
dictionary,
lookup
and
stuff.
B
B
It's
going
to
fall
back
to
reflection,
unfortunately,
but
in
terms
of
composing
custom
contracts
with
what
you
said,
I
would
expect
that
what
I
would
do
is
do
an
options,
dot
type
info,
resolver
dot,
get
type
info
and
then
pass
the
type
info
directly
into
the
root
level
root
level
methods
that
accept
json
type
info
as
the
parameter,
and
that
should
kick
off
a
pure
metadata-based
serialization
for
the
value
we're
interested
in.
I
H
I
Yeah
so
like
I
mean
this
is
the
the
old
example
right.
Let's
say:
I'm
I'm,
you
know
I
write
an
asp.net
app.
I
use
the
azure
sdk.
I
would
like
to
make
sure
that
I
use
you
know
the
source
generated
stuff.
The
azure
sdk
provides
for
its
own
types,
but
then
you
know
for
some
of
my
own
types.
I
want
to
use
a
custom
type
resolver,
because
I
want
to
tweak
the
settings
on
it.
I
I
don't
want
to
put
attributes
on
my
types
does
this
now
mean
if
I
do
that
I
basically
opt
out
the
entire
azure
sdk,
also
out
of
source
generation
and
everything
is
not
reflection
based
or
can
I
say,
yep
use
source
generation
for
as
much
as
possible
only
for
the
types
that
you
know
I
would
like
to
mess
with.
I
mean
sure,
use
reflection
for
that,
because
you
know
I
I'm
doing
runtime
stuff
for
those.
B
That
is
absolutely
absolutely
that's
absolutely
consistent
with
the
proposed
design.
I
would
think-
and
you
don't
even
need
to
fall
back
to
reflection,
doing
that,
like
you,
you,
you
would
be
able
to
write
a
resolver
that
you
know
composes
with
json
serializer
context
and
does
a
bunch
of
changes
on
the
contract.
I
I
don't
see
any
reason
why
you
shouldn't
be
able
to
do
that,
but
that
being
said,
I
I
somehow
feel
that
it
invalidates
the
purpose
of
source
gen
like
the
purpose
of
sourcing.
B
Is
that
you
know
you
have
this
meta
metadata
object.
That
is
hard
coded
in
in
in
c
sharp,
like
you,
you
just
instantiate,
it
call
it
you're
done
now,
you're
doing
a
bunch
of
what
amounts
to
reflection.
I
would
say
to
make
a
few
changes
and
as
soon
as
that
happens,
you
know
why
not
just
use
the
the
the
the
reflection
based
serializer
in
the
first
place
like
it
doesn't
seem
like.
B
B
I
Just
I
just
don't
know
what
the
code
would.
That
would
be.
So
basically
what
you
said
earlier
about
you
know.
Yes,
you
can
do
that.
I
just
don't
understand
what
code
I
would
write
to
make
that
happen.
I
guess.
H
You
wouldn't
be
sorry,
sorry,
I
just
want
to
say
it
just
sounds
like
that
would
be
like
whatever
union
strategy
we
come
up
with,
or
you
know
we
talked
about
union
in
the
context.
Union
and
resolvers
context
is
essentially
resolver
in
this
case.
So
it
just
seems,
like
you
know,
it's
whatever,
like
you
get
yes
yet
to
be
designed
is
what
I
would
think,
but
I
don't
know
if
this
is
a
separate
like
sort
of
amaga
mission
than
just
the
stuff
we
talked
about
before,
like
that.
We
should
circle
back
to.
B
Like
there's
a
there's,
a
bunch
of
concerns
as
well
to
be
addressed
like
what
happens,
if
you
combine,
if
you
union,
like
you,
said
two
different
contexts
and
they
happen
to
define
different
contracts
for
the
same
type
like
there's
a
there's,
a
whole
bunch
of
concerns
around
you
know,
conflicts
that
are
probably
best
left
to
the
user
in
the
first
place,
and
you
know
one
way
of
disambiguating
would
be
you
know,
chaining
them
in
a
specific
order,
but
there
might
be
other
concerns
as
well
and
it
it
seems
like
it's
something
best
left
to
the
user
and
we
shouldn't
necessarily
be
advocating
for.
B
Oh,
this
is
our
default
resolution
semantics.
This
is
our
default
resolution
order
because
I'm
kind
of
guessing
that
in
real
world
applications
there
will
be
all
sorts
of
random
types
that
need
to
be
accounted
for
from
different
sources,
be
like
nougat
packages
containing
json,
json,
serializer
context,
definitions
like
it
could
be
a
bunch
of
contract
resolvers
that
you
know
do
a
bunch
of
changes
on.
You
know
that
property
names
or
what
have
you
like
these
things?
H
Just
the
other
thing
to
verify
with
source
10
is
like
search
genesis
use
one
so
for
whatever
union
of
contexts
or
resolvers
they'll,
they
all
need
to
share
the
same
options.
Instance,
I
think
conceptually.
So
I
guess
the
one
thing
to
verify
resource
10
is
that
you
can
actually
share
the
options
among
the
different
context,
slash
resolvers.
I
don't
think
that
that's
we
have
that
one-to-one
mapping
to
this.
I
think
that
will
just
need
to
be
extended.
As
you
said
earlier,.
B
B
This
should
work
right
and
we
need
to
attest
for
that,
but
I
would
probably
think
that,
as
soon
as
you
write
your
own
custom
contract
resolvers,
I
think
that
the
the
way
of
resolving
metadata,
that
is
more
natural,
that
has
more
mechanical
affinity
with
that
abstraction.
That
would
be
json
serializer
options
based
dictionary,
lookup
keyed
on
type
for
getting
the
json
type
info
that
works
for
you.
I
I
I
don't.
B
I
I
I
guess
me
the
takeaway
is
kind
of
like
a
you
know.
I
would
like
to
see,
I
guess
a
code
sample
that
just
shows
that
I
think-
and
I
think
it's
reasonable
to
say
it's
out
of
scope
too.
Like
I
mean
I
did
not
try
to
say
like
they
have
to
compose
right
what
you
said
earlier
about
that,
it
seems
unlikely
that
somebody
wants
to
combine
source
generation
and
custom
type
resolution.
I
I
Right
yeah,
I
think
that's
a
fair
statement
too.
I
had
one
more
question
like
on
the
json
type
info.
I
The
non-generic
one,
the
converter
and
kind
are
not
settable.
Is
that
intentional?
Yes,
so
why
can
I
set
the
converter
on
the
property,
but
not
the
type.
A
A
I
see-
and
we
also
chose
different
names
here
because,
like
if
you
don't
override
it,
it's
it's
so
in
here.
Actually,
it's
nullable
also
right,
so
that
means
okay.
I
actually
didn't
want
that
default
or
not.
A
A
Not
the
kind
you
don't
have
a
way
to
specify
it.
The
kind
is
more
like
like
when
you're
referring
say
to.
Let's
say
you
want
to
extend
the
default
implementation
and
you
want
to
to
every
single
possible
proper
to
every
single
possible
type
which
has
properties
or
can
have
properties.
You
want
to
add
another
property
for
whatever,
like
version
or
god
knows
what
or
or
date
time
or
something.
I
don't
know
what
like
what
what
people
can
think
of,
but-
and
you
want
to
actually
know
if
that
thing
supports,
having
properties
or
not.
A
You
have
to
have
a
way
to
to
to
be
able
to
tell
that,
and
the
json
method
at
a
kind
is,
is
the
way
to
tell
that.
Basically,
so
we,
if
we,
if
it's
object,
basic
onset
properties,
yeah.
B
With
arcs,
or
something
like
that
and
under
the
kind
enum,
the
value
of
the
kind
enum
derives
from
the
converter
in
the
first
place.
So
you
know,
if
I
specify
a
custom
converter
for
my
poco,
then
you
know
tough
luck.
Metadata
no
longer
applies
you're
using
a
custom,
converter
and
you're
on
your
own.
B
So
you
know
if,
if
that's
the
converter,
we
were
associated
with
a
given
options.
Instance,
then
it's
a
done
deal.
The
the
converter
is
fixed
and
therefore
the
kind
is
set
to
none.
Therefore
you
know,
for
all
intents
and
purposes,
it's
going
to
be
a
whatever
changes
you
make
in
the
modern
will
be
a
know-off.
I
H
Have
this
feature
we're
considering
for
7.0,
which
is
to
allow
users
to
have
access
to
the
internal
converters
that
we
have
like
object,
dictionary
and
things
like
that,
so
you
slap
on
attributes
like
well
like
you,
should
have
a
converter
that
has,
like
you,
know
the
internal
json
object
converter
and
that
I
think
that
sort
of
interfaces
with
this
kind
property
where
like,
if
you
specified
you
like
object,
converter
for
a
dictionary,
for
instance
like
okay,
don't
modify
this
as
a
dictionary,
but
you
know
look
at
the
like
properties
and
stuff
on
it.
H
So
that's
one
way
we're
allowing
users
to
modify
the
kind.
So
I
wonder
whether
this
should
be
mutable
to
have
like
a
like,
like
another
ghost
like
a
way
to
do
it
at
runtime,
basically,
as
opposed
to
just
designed
to.
B
We
kind
of
considered
that,
but
unfortunately,
it's
not
possible
because
you
know
when
you
get
to
the
point
where
you
create
the
json
type
in,
for
instance.
Basically,
the
converter
that
you're
using
for
that
given
type,
is
already
committed
and
locked,
and
therefore
you
know
making
it
possible
to
change
it
via
a
setter
in
the
metadata.
B
It
seems
like
it
might
be,
introducing
too
much
complexity
to
force
the
change
upstream
in
any
of
the
caches
that
might
contain
the
previous
converter.
So
I
think
the
approach
here
should
be.
You
know,
specify
the
custom
converter
in
using
the
standard
way
by
going
in
the
options
instance
in
the
converters
list
and
assigning
it
or
assigning
it
via
an
attribute
and
then
separately
make
any
changes
you
might
need
in
the
metadata.
B
Although
typically
the
custom
metadata
resolvers
are
not
kind
of
written
to
act
on
individual
types.
Usually,
what
happens
is
that
they
kind
of
apply
blanket
policies
throughout
every
single
type
that
you're
serializing.
So
I
don't
necessarily
think
that
this
would
introduce
any
awkwardness
for
people
that
want
to
like
specifically
change
the
object,
serialization
semantics
of
a
very
specific
type.
That
should
be
configured
on
the
custom
converter
level,
yeah.
A
I
think
one
thing
to
consider
with
the
metadata
kind
maybe
is
like.
I
think
that
was
you
liami
who
mentioned
on
the
chat.
That
was,
I
think
that
was
anything
anywhere
public,
but
you
mentioned
that
we
might
want
to
add
the
create
object
with
arcs
or
something
similar,
and
in
that
case,
that
would
most
likely
introduce
another
enum
options
in
here
and
now,
if
users
check
the
object
and
say
we
add
something
like
objective
action
in
the
future,
then
maybe
like,
given
that
maybe
better
to
make
it
flux
explicitly
because
it
might.
I
A
A
Like
maybe
you
would
want
to
know
that
and
if
we
create
another
up
thing
like
objective
arcs,
you
technically
can
still
create
other
properties
in
here.
B
B
When
we,
when
we
do
add
support
for
parameterized
constructors,
I
think
it
should
just
work
with
pocos.
It
needs
a
bit
of
infrastructural
refactoring
other
wraps
because
currently
it
happens
to
use
a
separate
converter
implementation,
and
I
think
that's
a
good
signal
that
we
shouldn't
be
exposing
it
yet
like
having
a
separate
flag
just
because
our
current
implementation
detail
means
that
we
use
a
different
converter
for
constructor
deserialization.
I
don't
think
that's.
A
I
I
That
also
means
that,
whatever
combination
patterns,
you
are
thinking
of
you
need
to
consider
that
they're
not
complete
right,
so
you
would
have
to
do
potentially
both
right.
You
would
have
to
combine
the
converters
in
some
way
and
you
have
to
define
how
the
resolvers
are
composed
right.
If
you
can't
do
everything
by
other
resolvers,
that
is.
A
I
mean
technically
I
mean
it's
implementable
to
make
the
converter
suitable
and
but,
like
I
am
on
this
specific
case,
I
am
not
sure
because
let's
say
you
that,
let's
give
given
a
scenario.
Okay,
let's
say
I
use
the
default
json
typing
for
resolver
and
I
override
it
and
now
I
say,
base
dot,
get
type
info
and
I
get
the
something
with
the
converter
and
the
properties.
And
now
let's
say
I
change
the
converter.
A
Now
the
properties
might
change
the
semantics
into
something
which
it
was
not
meant
to
be,
and
it
might
just
throw
basically
at
this
point,
because
the
the
converter
is
no
longer
like
able
to
process
the
properties
which
I
was
given.
So
that's
kind
of
like
a
they're
like
really
weird
places
you
might
get
into
like
if
you
make
the
converter
setup.
Basically,
that's
that's
what
I'm.
I
Yeah,
I'm
not
saying
we
should
I'm
just
saying
like
from
a
from
a
conceptual
level
like
the
it
seems.
You
basically
have
two
extensibility
patterns,
but
you
have
the
one
via
the
the
type
info
and
you
have
another
one
via
the
converter
right
and
they
you
know,
do
different
things,
but
there's
some
overlap
right
and
that
that
pulls
a
challenge
is
when
you
think
about
how
they're
composing,
because
now
you
want
to
compose,
you
basically
have
to
compose
the
converter.
I
F
I
Somehow
build
an
instance
for
that
right
and
and
because
of
that
it
might
be
challenging
to
define
what
code
you
need
to
write
because
it's
like
oh
for
converters,
you
do
one
thing
for
typing
to
do
a
different
thing,
and
but
they're
not
orthogonal
right,
because
they're
interplay,
like
there's
only
one
combination
of
things
that
actually
works
right.
B
B
It's
it's
the
more
generic
mechanism,
but
the
problem
is
that
if
you
want
to
write
a
general
purpose
converter
for
pocos
from
scratch,
that
is
that's
a
lot
of
work,
and
so
what
json-type
info
is
it's?
Basically,
the
configuration
object
for
four
default
converters
that
we
currently
have
internally.
B
B
H
A
good
question
there's
a
statement
about
like
if
you
are
in
a
converter,
you
are
sort
of
on
your
own
and
then
metadata
doesn't
apply.
But
is
that
true,
especially
with
like
new
models
like
where
we
want,
because
users
complain
today
about
converters
being
difficult
they're,
mostly
for
primitives,
but
then
you
might
want
to
have
like
a
converter
to
handle,
you
know
objects,
and
then
you
want
your
list
of
properties.
So
I
I'm
like
how
does
that
statement
like
hold?
A
So,
basically,
you
want
to
write
a
custom
converter
which
is
able
to
pass
properties
to
to
parse
properties
or
like
what
rights
like
so.
F
A
Like
one
future
extension
point
so
basically
like,
I
cannot
think
of
it
as
the
json
type
info
being
like
a
bug
of
properties,
you
that
the
the
converter
is
using.
I
am
not
kind
of
constraining
this
like
in
my
mind,
at
least
that
this
is
an
internal
converter
specific,
but
like
currently
this,
because
the
conver
in
converter
you
kind
of
don't
have
access
to
that,
but
in
the
future,
technically
we
could
allow
access
to
for
the
json
type
info
inside
the
converter
and
then
be
able
to
read
that
back
of
properties.
A
Essentially,
you
could
entirely
in
the
future.
We
could
create
something
like
a
converter,
which
writes,
writes
an
example
type
rather
than
as
the
json
object
it
could
write
like.
I
don't
know
like
an
array
and
greater
purely
stuff,
so
basically
I
can
every
other
value
would
be
a
key
and
the
other
one
would
be
the
values
or
something
like
that.
That
could
technically
be
done
in
the
future,
but
it's
technically
not
constrained
to
that
but
like
currently,
it
is
because
we
don't
expose
it
anywhere
in
the
converter.
B
In
any
case,
like
the
main
thing
is
that
writing
custom
converters
is
hard
for
like
arbitrary
types,
especially
and
the
other
thing
is
that
custom
converters
are
fundamentally
restricted
because
they
do
not
pass
realization
state
and
they
cannot
be
async
at
the
moment,
so
that
basically-
and
that
was
actually
one
of
the
main
issues,
one
of
the
main
reasons
why
james
contacted
us
in
the
first
place,
because
he
actually
did
that
he
wrote.
B
You
know
he
wrote
a
custom
converter
for
for
his
grpc
model
because
he
can,
but
he
immediately
ran
into
performance
issues,
because
you
know
lo
and
behold,
the
custom
converter
was
buffering
the
entire
contents
of
the
serialized
or
the
serialized
json
like
it's.
B
It's
an
unfortunate
design
issue
with
system.json
and
its
custom
converter
model
and
json-type
info
will
give
us
access
to
configurability
for
the
baked-in
converters
that
support
async
support
threading
state,
like
do
all
those
all
these
fancy
things
that
you
know,
users
would
otherwise
need
to
implement
by
hand
reference
preservation
polymorphism.
H
So
quickly
as
it
relates
to
just
typing
for
kind,
do
we
need
an
announcement.
That's
this
converter,
especially
reader,
commenting
contract
method
that
doesn't
apply
here.
Like
sorry,
could
you
repeat
the
question?
Do
we
need
another
like
kind
that
is
like
this?
Is
a
custom
converter
or
not
like
it's
not.
A
Basically,
everything
other
than
non
is
like
a
built-in
converter.
Currently.
H
A
B
Of
of
converters
that
are
configurable
via
metadata,
you
can
have
other
things
like
you
know,
primitive
converters
or
custom
converters,
and
I
would
expect
with
a
feature
that
we
actually
pushed
out
of
seven
recently
to
have
more
kinds
of
converters
that
are
user
definable.
B
But
as
far
as
from
the
perspective
of
metadata
from
the
bounded
context
of
you
know,
customizable
metadata,
you
have
these
three
and
then
everything
else
is
know
what.
I
A
Almost
the
same
fields,
so
we
removed
a
couple
of
fields
like
value
because
it
currently
means
something.
F
A
It
suggests
so.
A
A
A
This
is
actually
called,
I
believe
it's
called
like
a
just
converted
strategy
or
something
like
that,
and
it
has
a
couple
of
more
things.
I
believe
it's
at
least
values
and
the
values
means
custom
or
custom.
Or
what
does
what
does
it
mean?
A
H
A
B
Way,
it's
also
used
as
a
flag
internally,
so
it
wouldn't
be
appropriate
to
surface
it
as
as
flags
in
in
this
context,
so
essentially
we're
mapping
the
internal
enum
into
this
genome
that
is
appropriate
for
consumption
in
in
metadata
customization.
I
A
I
mean
honestly,
like
my
initial.
My
initial
proposal
didn't
have
this
at
all.
I
would
kind
of
assume
if
user
wants
to
change
change
the
type
they
would
prop
on
the
type,
so
they
could
technically
check
like
if
the
type
is
assignable
from
like
a
dictionary
or
something
along
the
lines.
A
So
this
way
they
could
check
if,
if
they're
on
the
dictionary
on
the
marble,
but
they,
but
they
don't
have
a
100
solid
way
to
check
if
they're,
actually
on
the
object
and
if
we're
gonna
do
the
if
we
are
gonna,
actually
process
the
properties
or
not,
because
if
someone
assigned
their
custom
converter
now,
I
would
have
to
do
those
check
plus
if
this
is
my
custom
converter,
so
there's
basically
no
good
way
to
check
it.
A
Her
level,
however,
I
think
about
it,
but
on
the
other,
on
the
other
hand,
there
is
it's
not
really
a
common
scenario
to
do
that
at
all.
So
I,
but
but
there
are
some
scenarios.
Basically,
I
think
like
this.
This
specific
sample
over
here
like
actually
does
use
it,
but
in
theory
like
yeah,
so
this
specific
sample
actually
needs
it,
but
and
I'm
not
sure
if
there
would
be
a
better
way
to
to
write
this.
This
is
like
you
could
just
check
for
no
on
properties.
A
B
A
Now,
currently,
it's
only
about
the
properties
about
properties
and
objects.
So,
basically,
that's
the
only
thing
right.
A
I
A
So
how
so
what
do
we
do
about
this
now,
so,
basically,
do
we
continue
the
conversation
or
like
or
like
how
do
what
do?
How
do
you
proceed
from
here.
I
You
know
have
some
sort
of
sample
or
opinion
on.
I
guess
how
source
generation
and
custom
resolvers
interplay
makes
sense,
but
other
than
that,
I
think
it
looks
like
a
pretty
solid
proposal
already,
but
based
on
these
two
open
questions,
I
would
including
clients
the
same
market
as
needs
work,
and
then
you
come
back
with
the
updated
thing,
sounds
good.
A
Do
we
have
any
schedule
like
what's
the
earliest?
We
could
pick
this
up
next.
I
guess
so.
I
don't
know
if
you
have
any
I
I
know
this
week
is
already
booked,
so
probably
maybe
next
week
that
would
work
for
you.
So
I'm
pretty
sure
I.
B
I
I
mean
we
have
two
slots
right.
I
mean
you
could
literally
come
back
on
thursday.
If
you
wanted
to,
or
we
could
say
next
week
right,
it
depends.