►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello:
everyone
welcome
to
a
special
thursday
edition
of
api
review,
where
we
are
trying
to
get
rid
of
all
of
these
red
things
that
say
that
people
would
like
us
to
already
be
done
with
them
so
up.
First,
let's
resume
the
json
source
generation,
so
45488
naomi.
B
Thanks
so
on
tuesday
we
went
over
the
scenarios
and
goals
for
the
search
generation
for
system
technician
project.
So
just
quick
recap:
there,
just
faster
startup
and
lower
locks
and
startup
and
faster
throughput,
reducing
the
size
of
applications
where
possible
and
removing
io
linker
audience
where
possible.
B
So
today
I
just
I
want
to
go
over
the
apis.
That
developers
would
interact
with
as
they
try
to
use
the
search
generator.
So
a
few
scenarios
here
so
discussing
the
case
where
user
developers
are
using
system
takes
json
directly.
We
start
with
the
new
the
new
pattern
on
proposing,
which
is
new,
overloads,
accepting
the
generated
metadata.
So
you
specify
the
type
for
generation
with
the
attribute,
and
then
you
call
a
property
on
an
instance
of
the
generated
context
to
you
know:
pass
the
metadata
for
that
type,
specifically
for
serialization
and
visualization.
B
So
the
first
one
here
is,
I
I
know
that
code
was
generated
for
all
types
and
I
know
which
specific
type
I'm
processing,
so
you
can
generate
the
metadata
for
the
type
the
next
one
is
the
case
where
you
know
you've
generated
metadata
for
all
these
realizable
types.
But
you
don't
know
which
type
of
person
say
you,
you
get
the
type
from
some
method
that
returns
a
type
media
for
this
realization.
B
B
So,
as
you
main
custom
options,
we
provide
a
new
api
on
decentralized
options
called
set
context
which
accepts
and
a
generic
parameter
for
a
type
that
derives
from
distance
laser
context,
and
the
general
constraint
here
is
that
it
obviously
derives
from
the
context
and
also
has
a
public
parameters
constructor
and
the
public
purposes.
Constructor
is
meant
to
create
an
instance
of
that
context,
which
isn't
bound
to
address
industrializer
options
so
with
the
idea
of
binding
context
and
options.
B
So
so
the
point
where
you're
sitting
in
the
context,
both
the
context
and
options
should
not
be
found
at
that
point.
Can
I
answer
what
questions.
C
Yeah,
so
just
to
make
sure
I
understand
so
basically,
you
have
existing
code,
that's
using
json,
serializer
and
passing
around
options
to
use
and
all
of
your
method
calls,
and
in
one
place
I
can
say,
hey
options.
Here's
the
generated
source
that
you
should
know
about
and
then
any
other
uses
will
make
use
of
it.
That's
correct!
That's
correct
what
happens
if
I
presumably,
I
could
end
up
in
a
situation
where
I
actually
have
multiple
of
these
from
different
assemblies,
each
contributing
their
own
json
context.
B
So
in
this
I
am
not
yet
proposing
a
case
where
you
can
sort
of
do
a
union
of
context
from
different
places.
You
would
have
to
sort
of
partition
your
serialization
logic
to
understand
where
metadata
comes
from
and
when
you
can
use
it
to
realize.
What
type
later
on,
I
discussed
like
the
concept
of
a
global
static
where
you
can
populate
unbound
context
and
possibly
do
a
clone
with
or
if
some
like,
a
clone
or
fork
action
that
takes
certain
options
and
then
create
an
instance.
B
And
then
perhaps
you
can
create
like
utility
methods
that
do
some
sort
of
merge.
Now.
Basically,
I
think
the
most
relevant
method
for
something
like
that
would
be
to
get
the
type
info
for
a
type.
So
you
could,
you
know,
look
through
all
the
type
of
like
the
context
instances
you
had
and
I
have
and
see
whether
any
one
of
them
have
the
type
of
data
forecast.
B
It's
a
little
bit
tricky
to
have
that
sort
of
global
static
or
global
registration,
because
you
know
it's
global
and
then
multiple
folks
can
be
trying
to
add
context
that
provide
metadata
for
a
certain
type.
And
it's
a
question
of
like
which,
which
one
would
you
pick?
Which
one
should
you
order?
You
might
assume
that
all
of
the
metadata
would
be
the
same,
but
that
is
not
correct
because
across
different
assemblies,
it
might
have.
You
know,
internal
members
that
are
not
visible
from
another
assembly.
B
So
there
might
be
cases,
however
corner
there
might
be
where
you
know
the
fact
that
it's
not
clear
what
order
to
use
might
mess
something
up.
So
I
mean
I
had
some
discussions
with
some
folks
here
and
there
on
the
sp
asp.net
team.
They
also
don't
like
that
concept
of
like
a
global
static.
Where
you,
you
know,
register
stuff
and
try
to
I
mean
I
don't
think
that
they
have
lots
of
those
yeah.
I
don't
know
what
the
guidance
is
around
things
like
that,
but
it
is
possible.
D
C
B
In
that
case,
since
the
options
are
local
and
you're
setting
them
in
an
order,
perhaps
you
could
say
you've,
you
specified
your
order
and
then
we
can
then
like
pick
some
sort
of
heuristic
to
say
whether
last
one
wins
or
first
one
with
when
we're
searching
through
for
metadata
for
a
type
as
long
as
it's
local.
So
you
know,
like
you
know
how
it
was
composed
and
I
think
it's
fine.
I
think
my
comments
earlier
are
more
about
the
global
registration
but
a
local
one.
C
B
Yeah,
it
would
be
in
that
case
would
be
at
context.
It
seems
like
we
would
have
to
make
some
sort
of
decision
about
that
now
or
maybe
just
go
with
this
for
now
and
then
come
back
to
it
later
on
I'd,
say
but
yeah.
C
We
can
keep
going
just
something
to
know.
Okay,
sorry,
just
just
last
question
on
that:
do
we
we
believe,
based
on
the
scenarios
that
you're
aware
of
we
believe
that
set
once
and
only
one
is
like
the
90
case.
B
I
would
say
like
a
lot
like
it's
hard
to
come
up
with
a
number,
but
I
would
say
like
at
least
four
like
asp.net
cases
like
things
we
know
of
concretely.
B
Yes,
like
the
proposal
satisfies
those,
but
I
I
would
say
more
than
if
a
couple
of
people
have
mentioned,
like
you
know,
if
I
want
to
take
the
metadata
from
multiple
places,
how
would
I
do
it.
E
F
I
mean
you
kind
of
want
the
way
to
compose
them,
though
right
because
I
mean
I
think
the
fundamental
problem
of
this
json
context
is
that
it's
an
internal
type
right.
So
that
means
you
know
my
library.
You
know
the
example
that
I
gave
naomi
was
cosmos
db
right,
cosmos
db
has
internal
types
that
they
use
to
serialize,
you
know,
as
for
the
protocol
with
their
back
end,
and
they
also
accept
user
types
and
the
user
types
are
part
of
the
payload
descent
to
the
server
right.
A
I
mean
nothing
in
the
current
design.
Stops
you
from
doing
that
they,
even
if
there's
not
a
generator
option
to
make
the
class
be
public.
You
could
somewhere
expose
a
public
json
serializer
context.
Whatever
the
base
class
is
called.
That
is
just
your
default
context,
and
then
you
can
make
a
custom
context,
because
it's
a
public
type,
that's
not
sealed
and
walk
the
order
of
that.
You
want
to
walk
through
the
resolvers
for
get
type,
so
it
I
think
it's
possible
right
now.
It's
just
not
trivial.
A
B
Yeah,
the
add
context
approach
would
appear
to
work,
there's
also
the
possibility
of
like
an
api
to
system
together.
B
If
I
can
come
back
with
with
that
later,
oh,
I
think
that
would
be
fine,
but
it
doesn't
seem
like
too
much
work
to
to
go
from
here.
To
then
and
like
in
in
the
next
preview,
I'd
say.
F
B
Yeah,
the
only
the
reason
to
do
this
is
to
help
existing
code
like
work
in
cases
where
people
don't
want
to
to
change
their
code.
That
was
one
of
the
feedback
I
came
from
from
tuesday,
where
we.
F
D
B
Yeah,
that's
that's
correct.
Just
the
thing
to
note
there
is,
it
doesn't
come
with
the
like
linker
trimming,
because
that
overload
for
backward
compact
will
have
the
reflection
code
in
there,
so
a
fallback.
So
if
the
type
doesn't
exist,
I
guess
the
one
benefit
is.
If
your
context
doesn't
contain
the
type,
then
the
serializer
will
generate
it
for
you.
B
So
maybe
we
don't
need
the
merging
stuff
if
that's
fine,
depending
on
the
characteristics
but
as3.net
at
a
higher
level
might
decide,
because
today,
they're
limited
for
to
this
pattern,
where
you
register
the
generated
stuff
on
the
context,
because
it's
difficult
for
them
to
tease
about
their
code
to
have
separate
code
files
where
they
can
link
out
existing
calls
to
the
serializer
that
that
does
reflection.
D
B
B
So
the
this
the
generic
constraint
here
is
that
it's
a
parameters
constructor
and
that's
when
you're
near
one
of
the
json
context
it
doesn't
set
on
options
so,
like
early
iteration
of
this
I
had
was
you
know,
you
just
passed
the
new
json
context,
but
I
got
some
good
feedback.
You
know
where
to
sort
of
stop
users
from
having
to
reason
about,
like
you
know
what
kind
of
like,
how
do
I
instantiate
the
the
context?
So
this
way
we
do
it
for
you
just
because
we
have
a
giant
question.
B
We
just
need
new
update
context
and
and
have
it
that
way.
So
it's
more
of
a
convenience
thing
and
like
less
of
a
concept
for
people
to
to
know
how
to
because
if
you
set
one
of
these
that
that
you
instantiated
with
an
option
we'll
throw
an
invalid
operation
exception,
saying
the
context
was
already
bound.
But
this
way
you
don't
have
to
think
about
that.
C
H
C
D
B
Just
like
do
you
want
to
use
the
default
default,
desensitized
options,
so
it's
different
from
this.
A
B
G
B
B
Yeah,
it's
always
be
just
in
context,
because
that's
what
we
name
and
we
don't
have
provide
like
we
don't
provide
like
a
way
for
you
to
rename
it
for
now.
But
if
we
did
then
yeah
your
whatever
your
name
is.
A
Yeah
for
like
with
the
public
api,
I
think
right
now.
Somebody
could
write
this
merged
context
that
I
just
whipped
up
in
notepad,
so
it
probably
won't
compile
but
like
because
all
you
have
to
do
is
defer
the
call
to
get
type
info
and
the
other
now
get
type
info
so
and
picking
options
I
guess,
but
like
it,
it
seems
solvable
that
somebody
could
build
this
if
they,
if
assemblies
made
a
public,
json
serializer
context
somewhere,
so
everybody
would
have
to
participate,
of
course,
but
I
think
it
is
doable
right
now.
B
Yeah,
the
datas
can
be
bound,
I
think,
the
instances-
okay,
so
yeah
existing
pattern.
I
don't
know
what
type
then
so
this
is,
I
know
the
type,
so
you
pass
the
options
and
then
I
I
don't
know
the
type
you
still
pass
the
options
and
you
pass
the
type
like
the
exact
usage
of
the
serializer
today.
B
So
moving
on
to
using
system
existing
directly.
So
asp.net
core
is
like
an
example.
So,
in
the
case
of
blazer,
this
is
what
the
code
would
be.
You
would
specify
the
you
know
the
type
you
want
to
perform.
Serialization
and
utilization
on
you
instantiate
on
options
like
your
contact
system
options,
and
you
pass
that
to
a
new
proposed
api.
G
B
G
G
F
A
Yep
right
well
from
the
like,
I
think,
naomi's
next
thing
is
really
asp.net,
etc,
like
they
can
still
get
it
from
the
current
thing,
by
changing
the
options
to
be
abound,
options
with
the
the
ad
or
set
or
whatever
context.
A
G
Well,
two
two
things
like
the
the
first
one
is
like
how
blizzard
works
today
and
there's
no
real
work
around,
because
that
method
get
from
dismissing,
I
believe,
is
on
http
client,
so
yeah
so
and
there's
no
injecting
other
contents
that
doesn't
get
passed
in
directly.
So
even
if
we
we
use
the
ui
it,
wouldn't
it
wouldn't
help
as
emo
said,
because
you
have
to
inject
it
into
every
single
class,
but
that
that
is
an
issue
we
have
today
even
with
options.
So
that
needs
to
be
solved
in
a
different
way.
B
Okay,
yeah
so
empty
so
yeah.
The
next
point
so
nvc
the
if
svl.net
services
can
allow
users
to
to
specify
it.
This
way,
you
don't
get
the
link
or
benefits
for
today,
but
a
couple
of
options
include
providing
an
api
that
takes
that
allows
the
user
to
return
a
json
context,
in
instance,
and
then
I
think,
there's
more
underlying
work.
That
needs
to
be
done
to
like
refactor
the
code
such
that
the
calls
to
the
serializer
I
trimmed
out
the
ones
that
will
root
the
reflection
code.
D
B
So
other
libraries
have
the
option
to
basically
expose
apis
that
either
take
the
options
or
context
and
anything
else.
If
it's
like
not
really
possible,
we
discussed
like
global
statics,
we
discussed
merging
option.
Well,
I
don't
know
what
that
meant:
yeah
merging
options
from
a
global
static,
I
guess,
would
be
the
way
to
go,
but
I
guess
that's
not
really
a
direction
I'd
like
to
like
start
working
on
unless
it's
like,
there's
a
concrete
scenario
that
needs
to
be
solved
for
okay.
If
you
have
proposal
honestly
any
questions.
F
Cameron
was
basically
the
the
side
where
I
call
a
rest
api
right,
but,
like
I
think
that
the
more
common
case
in
the
html
would
be.
You
write
an
effect
of
the
event
api,
where
you
just
write
a
method
that
returns
an
initial
of
customer
and
then
yep
transitively,
like
not
sorry,
transparently,
serializes
those
types
on
your
behalf
right
in
that
one,
you
can
totally
solve
of
a
api
that
you
just
call
it
the
startup
method
right,
because
that's
that's
kind
of
the
user
has
to
kind
of
pass
their
json
context
to
a
spin.
F
G
That's
right,
yep,
the
the
one
thing
that
isn't
api,
but
that
that
bugs
me
is
that
you
have
to
list
all
the
generic
kind
of
instantiations
like
list
of
blah
array
of
blah
to
serialize
those
types
too.
That
would
that
would
definitely
trip
people
up
in
in
preview
4.
But
it's
fine,
we'll
figure
it
out
later.
B
B
The
assembly
were
compiling
to
see
what
these
are
being
passed.
If
it's
discernible,
like
you
know,
if
it's
like,
if
they're
recorded
to
serialize,
then
it's
easy.
If
it's
a
generic
like
nested
in
a
bunch
of
generics,
then
I
haven't
tried
it.
It
might
be
harder
and
you
might
still
need
to
attribute
for
cases
like
that.
But
at
least
maybe
it's
more
easy
to
to
understand
why
you
had
to
put
the
attributes
yourself.
H
B
Yeah,
the
other
thing
is
like
anything
that
can
be
like
serialized
like
polygraphically,
meaning
the
instance
like
say
you
have
an
object
array
and
the
things
you
have
in
there
like
intern
string.
You
need
to
specify
those
because
there's
no
way
to
metadata
for
those
who
live.
Okay,
so
just
first
thing,
json
series
options
add
in
this
method
set
context.
Maybe
later
it
makes
it
sense
to
change
it
to
add
context,
but
pronounce
that
context
where
one
more.
F
Question
so
like
on
this,
so
if
we,
if
we
say
that
serializer
options
basically
have
the
half
the
context
right,
maybe
if
may
say
this
is
this:
this
is
the
solution
to
the
to
the
problem
that
people
have
to
pass
the
context
around
you.
Then
you
also
said,
like
it's
still,
not
linker
friendly
right,
so
every
single
api
that
today
only
takes
the
options,
or
I
should
say
that
doesn't
take
the
context,
wouldn't
be
linked
or
friendly,
because
it
would
have
to
have
a
fallback
to
reflection
right,
yeah.
B
F
B
E
A
thing
we
didn't
fully
go
into
last
last
time
was
for
xamarin
and
for
blazer
wasm.
The
linker
warnings
aren't
going
to
be
on
by
default
because
because
all
we
trim
by
default
in
those
cases
is,
is
the
bcl
assemblies
and
so
like.
If
you,
if
we
turned
them
on
in
six,
everybody
would
get
a
ton
of
warnings
and
it
would
be
a
lot
of
noise
as
well.
C
F
A
Yeah,
I
think
we
would
still
annotate
the
current
serialize
and
deserialize
methods
to
be
the
unreferenced
code
attribute
or
whatever,
but
it
wouldn't
be
hyperviral
because
it
will
stop
at
the
first
assembly
boundary
if
I
understood
eric's,
interpretation
of
or
a
statement
of
the
universe.
F
E
When
warnings
are
on-
and
you
call
the
existing
serialized
method,
you'll
get
a
warning,
then
at
that
call
site
and
what
we
we
would
tell
people
is,
if
you
care
about
those
warnings,
and
you
want
to
fully
trim
your
app
call.
The
other
overload
that
takes
in
the
context
that
doesn't
have
the
fallback
that
one
is
100
trim,
safe.
F
E
So
today
it's
it's
everything.
They
have
plans
to
change
that,
if
you
don't
have
the
source
code
for
a
place
like
say,
there's
warnings
in
a
referenced
assembly
there's
only
they're
going
to
collapse
them
all
into
one
reference.
One
warning
saying:
hey:
you're,
referencing,
joshua's,
nougat
packet.
It's
not
linker
friendly.
F
Yeah,
I
was
thinking
of
like
you,
use
cosmos
db,
where
the
class
wants
to
be
called
the
existing
json
options
that
overloads
and
doesn't
pass
in
the
context,
then
my
app
would
get
warnings
because
cosmos
is
calling
that
and
I
can't
fix.
E
Right,
if
you
were
trimming-
and
you
had
warnings
on
in
your
app
you'll,
get
one
warning
from
cosmos
db,
saying
cosmos
db
is
calling
things
that
aren't
micro
friendly.
So
david
has
a
comment
in
the
chat
we
had
this
discussion
about
laomi
and
I
had
this
discussion
about
adding
a
feature,
a
feature
switch
that
would
that
would
take
out
the
reflection.
So
when
you
turn
this
thing
on,
it
would
take
out
that
reflection.
E
Call
the
the
issue
with
that
is
the
user
experience
kind
of
stinks
in
my
opinion,
because
I
going
along,
I
have
that
flag
turned
on
and
everything
works
and
then
I
go
use
cosmos
db
and
then
cosmos
dgs
breaks
that
run
time
right
because
it's
like,
oh,
I
can't
find.
I
can't
find
you
know
metadata
for
foo
type
and
now
what
now
you
have
to
turn
that
flag
off
and
now
your
your
stuff
gets
bigger.
E
C
J
E
A
B
Yeah,
I
think
it
depends
there
might
be
cases
where
it's
safe
and
and
not.
I
think
david
and
I
discussed
yesterday
possibility
of
asp.net
offered
as
option
for
their
users
at
their
level
right,
so
you
could
yeah.
Just
not
system
takes
you
certain
level.
I
don't
think.
E
E
A
G
Like
trim
the
reflection
code,
even
though
we're
using
it
in
in
the
library
in
case
the
user,
knows
that
their
code
is
safe,
but
I
guess
it's
unsafe
because,
like
if
you,
if
you
call
anything
else
in
in
the
process,
it
might
barf.
But
I
don't
know.
D
A
The
the
late,
the
late
association
with
data,
where
you
have
the
runtime,
if
is
where
yeah
the
linker,
can't
help
so
yep.
F
A
If
you're
the
application
and
you're
doing
direct
calls,
then
if
you
never
called
the
one
that
took
options,
then
the
linker
will
trim
it
out.
It's
only
when
you're
an
asp.net
application,
where
something
in
the
middle
layer
has
this.
If
I
found
an
ambient
context
called
a
context,
would
otherwise
look
for
an
ambient
options
and
call
the
options,
one
that
the
linker
says.
D
A
A
But
that
mean
that
you
could
do
the
same
thing
right
now.
If
they
I
mean
okay,
fair
enough,
there
may
need
to
be
some
magic
to
let
the
we
had
an
asp
call
pattern,
and
I
get
to
scroll
this
to
make
this
world
work
nicely.
A
F
E
I
mean
to
tell
you
the
truth.
I
don't
even
like
the
proposed
set
context
of
t
thing
at
all
like.
I
think
it
should
take
a
jason
serializer
context
instance
because,
like
in
jeremy's
case,
where
he's
like
well,
I
wanted
I
wanted
to
create
my
own
and
add
things
to
it.
How
would
I
ever
get
it
like?
How
would
I
ever
get
the
instance
to
like
add
things
to
it
with
the
current
apis
proposed.
A
Yeah
I
mean
so
yeah.
As
I
said,
I
had
suggested
to
leomi.
He
used
to
have
it
taking
an
instance
and
I
had
suggested
making
it
generic
just
so
we
could
avoid
the
state
where,
when
you
meet
the
two
things
together,
the
options
can't
already
know
about
a
context
with
the
current
implementation
and
the
context
can't
already
know
about
an
options,
because
now
you
have
potentially
conflicting
options,
and
so
it
was
the.
If
we
think
that
the
case
is
simply
that
somebody
needs
to
specify
the
type
then
great
make
it
a
generic.
A
You
have
the
type
safety
you
have,
the
reference
to
the
thing
everything
works
and
you
didn't
get
in
the
argument
exception
of
I'm
sorry.
The
context
you
gave
me
already
knows
about
its
options.
This
is
now
an
invalid
combination,
because
every
context
needs
an
options,
but
it
can't
have
an
options
if
you're
changing
the
relationship
on
them,.
A
A
Don't
this
of
new
of
jason
context
that
default
and
who
are
we
saying.
D
A
B
B
No
because
you
know
you
need
to
pass
instances
to
the
serializer.
B
So,
unless
we're
doing
a
bunch
of
stuff
lazily,
it
just
complicates
things
I'm
to
to
not
have
it
frozen,
because
once
it's
frozen
like
within
the
context,
we
know
that
we
can
segment
it
appropriately.
B
If
it's
not
frozen,
then
we
have
to
write
a
bunch
of
code
to
delete
things
until
we
know
that
the
first
realization
has
happened.
It's
a
little
bit
more
complex
code.
So
unless
there's
like
a
reason
like
a
really
good
reason
to-
and
I've
lost
track
of,
the
the,
like
reasoning
for
you
wanting
to
do
that
in
this.
In
this
case,.
B
E
B
A
Yeah,
like
in
the
case
of
this
relationship
like
it
seems
like
it
should
be
able
to
work.
You
basically
just
need
to
hold
the
delayed
like
you
need
to
just
not
instantiate
the
thing
until
the
first
serialize
and
be
like.
Oh,
I
have
a.
I
have
a
pending
call
to
go,
build
a
context.
I
can
go,
build
it
and
wrap
it
or
wrap
myself
in
it
or
whatever.
A
B
Yeah,
that's
the
thing,
so
I
guess
you
can
delete
until
you
ask
for
the
first
property,
but
once
you
do,
then
it
just
makes
the
generation
code
a
lot
more
tricky
and,
like
the
the
things
were,
passing
to
create
metadata
all
have
to
be
found
to
say:
wait,
don't
do
it
until
the
realization
has
started,
which
may
be
a
good
thing
in
some
cases
like.
A
Like
I,
I
think
just
remembering
how
your
implementation,
you
showed
of
the
context
and
thinking
of
how
the
serializer
works
if
the
current,
if
the
call
to
add
context,
just
tells
the
options
when
I
seal
myself,
I
need
to
go,
create
a
context,
and
it
just
basically
sets
a
bit
of.
I
need
to
do
that
work.
Then
you
would
end
up
not
creating
the
context
until
after
the
serialization
options
were
themselves
already
locked.
F
I
have
a
fundamental
question
like
who
is
actually
using
this
set
context,
because
I
mean
we
said
in
the
context
of
asp.net
but
like
in
the
context
of
asp.net
right.
You
either
set
it
up
in
the
eye
early.
But
you
say
here
are
your
easier,
json
context
that
you
will
use
and
that
can
use
whatever
mechanism
you
want.
We
don't
have
to
use
that
context,
so
we
could
just
have
a
you
know.
F
Whatever
the
services
you
want
to
use
in
asp.net,
so
json
options,
you
could
have
dot,
set,
json
context
right
and
then
it's
just
the
mechanism
instead
of
a
net,
so
who's
actually
the
primary
consumer
of
that
context,
because
basically
my
understanding
is
that
we
generally
want
user
code
and
library
code
to
stop
just
doing
options
and
we
want
them
to
instead
take
context
so
that
they
can
differentiate
between
what
is
bigger
family
and
what
isn't.
So.
We
now
tell
everybody
to
just
no,
no
just
stuff
your
json
context
into
the
options.
B
Set
context
is
to
satisfy
the
case
where
you
have
existing
code
that
doesn't
want
to
change
a
lot,
and
you
don't
want
to
use
our
analyzer
that
I
want
to
to
make
later
to
help.
You
change
your
code,
so
it
was
mostly
it's
entirely
about
that,
letting
like
the
old
code
work.
B
So
I
mean
if
it's
not
because
feedback
from
last
time,
if
it's
not
priority,
or
I
think
the
asp.net
scenario
they'll
just
be
forced
to
add
an
api
that
takes
the
context.
If
we
don't
have
set
context
now,
yeah-
and
you
know,
it'd
be
nice
to
have
something
to
announce
that
long
before
to
say
like
hey,
you
can
try
out
the
social
generators
using
this
like
upstream
thing,
maybe
houdini
or
something.
G
Yes,
please
yeah.
We
want
something
without
something
there.
By
default,
we
can
add
an
api,
it's
not
the
end
of
the
world.
I
just
want
to
make
sure
that
we
think
that's
the
right
thing
to
do
like
we'd
have
two
top
level
options
that
are
mutually
exclusive.
F
And
it
sounds
like
conceptually:
no,
there
is
two
different
ways
to
do
civilization
and
it's
viral
right.
So,
like
you
either
want
json
context
all
the
way
down
or
you
just
it's
good.
I
don't
care
about
that.
They're
just
options
all
the
way,
but
like
now
we're
saying
oh,
we
kind
of
do
both
and
then
you
just
inspect
the
options,
but
it
has
a
context
and
then
that
party
decides
to
do
this
if
statement,
but
that
thing
then
actually
was
not
a
more
complicated
design
than
the
other
one.
F
Because
now,
like,
let's
say
I'm
causing
whatever
I
expected
to
do,
do
I
take
it.
Do
I
continue
to
take
json
options?
Do
I
take
both
json
options
in
json
context?
What
do
I
only
take
json
context
because
it
has
an
option
right
because
both
both
have
the
other
right,
so
it's
not
clear
what
what
what
we
want
people
to
do.
B
Yeah
yeah
default
yeah.
It
helps
us
avoid
the
fallback
and
know
that
we
don't
have
to
root
code
and
that's
the
downside
of
the
yeah
of
any
any
design
that
involves
like
it's
inheriting
from
jason's
realized
options.
Unless
we
have
json
series
our
context
itself
inherits
from
that,
then
we
can
add
overlays
for
that
specifically
and
then
hopefully,
like
the
the
type
binding,
does
the
right
thing
and
then
we
know
when
we
go
to
the
correct
overloads
yeah.
All
of
that
to
see
is
that
it
was
all
about
the.
K
A
The
even
calling
the
serializer
that
takes
the
context
instead
of
the
type
info,
that's
still
rooting,
everything
that
you
told
the
thing
to
generate,
because
it'll
walk
through
the
the
type,
waterfall
or
david's
brilliantly
evil
array
based
on
generic
instantiations
like
because
all
of
the
all
of
that
will
be
will
seem
to
be
reachable
code,
so
it'll
keep
all
of
the
types
and
it'll
keep
all
of
their
properties
in.
A
E
A
E
A
B
So
do
we
want
self-contact
still
the
reason
I
did
was
feedback
around
existing
things
working
but.
C
I
mean,
I
think
it's
still
valid
like
there
are
multiple
goals
we're
trying
to
attain
here,
one
of
which
is
around
making
your
app
smaller,
but
that's
not
the
only
goal.
I
also
want
faster
startup.
I
also
want
sustained
fast
throughput
and
using
a
compiler.
You
know,
compile
time
generated
thing
that
helps
me
start
up
faster
is
valid,
even
if
I'm
not
trimming
my
app,
I
feel
like
we
should
be
able
to
attain
that
without
having
someone
rewrite
all
their
code.
C
F
I
mean
the
problem
is,
like
even
scenario
is
not
very
likely
to
get
a
lot
of
feedback,
but
I
think
it's
valid
right.
Just
because
it's
I
mean
yes,
we
try
to
make
a
linking
work,
but,
like
there's
other
benefits
you
get
from
that
and
the
question
is:
how
do
I
get
those
without
changing
the
universe
right
and
they
don't
think
that
doing
videos
we
very
like
to
tell
us
that.
That's
the
part
that
they're
having.
F
The
question
will
be
how
right,
because
I
think
I
mean,
for
example,
you
could
imagine
that
one
of
the
design
points
would
be.
Oh,
we
wish
jason
still
has
the
options
for
additionalization,
sorry,
just
until
the
other
context
would
have
derived
from
json
as
options
or
something
right
like
those
are
the
kind
of
things
that
we
would
have
to
decide
now
of
that.
So
if
we
are
confident
we
can
edit
that,
but
depending
on
where
the
design
is
going,
that
might
be
harder.
F
A
I
don't
know
that
we
would
want
to
have
done
that
emo,
because
it
would
mean
that
we
have
a
bunch
of
properties
based
on
the
current
design
criteria
and
the
current
design
or
current
implementation,
a
bunch
of
properties
that
set
themselves
on
first
read
by
reading
the
options
that
would
then
be
on
the
same
object
as
all
the
options
that
you're
supposed
to
be
able
to
fiddle
with
it
would
be
very,
very,
very
bad.
To
ever.
Have
I
mean
we
need
to
tell
the
debugger
not
to
evaluate
any
of
those
properties,
otherwise,.
F
I
think
I
want
to
shift.net
six
and
knowing
what
the
design
is
to
make
even
scenario
work
like.
I
don't
want
to
start
designing
this
thing
by
the
time.
I
do
seven
because
I
don't
have
confidence
that
you
know
this
will
just
work
like
because
of
the
interactions
of
the
me,
maybe
the
behalf.
I
just
finally
make
an
example
by
this
obvious,
but
yeah,
maybe
not.
G
If
we
keep
set
contacts,
then
it'll
be
compatible
with
all
the
apis
we
have
today,
but
those
things
won't
be
able
to
link
stuff
out,
which
is
probably
fine
for
for
asp.net,
since
that.
Doesn't
that
isn't
the
permanent
scenario
for
linking
right
now,
but
I
don't
know
how
it
tains
the
design
of
like
the
contacts,
because
it
does
seem
weird
that
they're
linked
both
ways,
but
maybe
it's
temporary.
So
we
can
think
of
a
better
solution.
C
B
I
yeah
they
don't
have
the
benefit
like
the
benefits
of
the
betas.
Like
the
I
guess.
The
only
benefit
is
say
you
just
get
some
type
from
nowhere.
Then
you
might
want
to
use
that.
But
if
you
are
like
iot
friendly
there's,
you
know
the
closure
is
well
understood.
I
think
you'd
always
want
to
use
the
newer
stuff.
G
B
You
can
use
our
advanced
apis
to
add
metadata
yourself.
We
don't
want
you
to
do
that,
but
that's
one
thing.
The
other
thing
is
just
to
generate
your
context
and
use
the
existing
overload.
C
Yeah,
I
mean,
I
think,
david's
david's
question
is
really
more
along
the
lines
of
do.
We
provide
an
on-ramp
for
someone
who
and
david
correct
me
if
I'm
wrong,
but
you're
great
wholesale
to
the
new
apis,
so
you
always
require
a
context
and
I've
got
you
know
50
of
my
things
using
source
generator,
but
I'm
still
getting
types
from
elsewhere.
C
I
can
still
use
the
new
call
sites
if
I
am
able
to
create
adjacent
context
for
some
type
for
which
I
one
wasn't
compiled
generated
for
me
and
then
over
time
you
know
change
my
change
change,
my
apis
to
be
passed
to
the
relevant
thing
because,
as
we
discussed
last
time,
this
json
context
thing
is
viral
right.
You,
if
you
have
to
pass
one
in
then
you
have
to
be
given
one
along
with
the
type
that
you
want
to
be
serialized.
A
G
N
G
A
I
mean
calling
this
calling
that
method
to
get
that
type
info.
That
would
be
right
requires
unreferenced
code.
So
you
you
just
like
everything
else
in
the
world.
You
have
the
choice
of
dynamic
or
good,
linking
or
good
trimming
right,
so
it
I
think
this
is
just
the
hook,
for
how
can
you
get
a
type
info
to
add
into
the
world
for
a
type
that
somebody
didn't
pre-generate
and
it
seems
like
a
reasonable
api
again.
A
O
O
Right,
I
think
such
an
api
is
useful
and-
and
I
think
the
easiest
way
to
think
about
this-
is
that
the
old
apis
there's
one
line
of
code
at
the
beginning
that
says
json
type
info
equals
you
know,
get
from
reflection
and
passes
in
the
type.
That's
essentially
what
happens
today
and
then
the
new
methods
are
missing.
That
line
of
code
yep.
C
So
today
my
understanding
of
the
70k
or
whatever
it
is
that
we
save
from
for
trimming
with
all
this
stuff
is
that
it
some
of
it
is
reflection
itself,
but
some
of
it
is
also
a
ton
of
other
types
that
we
end
up
rooting
just
in
case.
One
of
them
may
have
been
in
a
graph
like
immutable
collections.
C
Is
my
understanding
correct,
yeah?
It's
both.
Would
we
if
we
went
with
something
like
this?
Would
this
enable
us
to
at
least
get
rid
of
all
of
that
rooting
for
immutable
collections
just
in
case,
even
though
we
might
still
have
to
keep
reflection
like
if
I,
if
I
only
use
the
new
apis,
but
I
used
that
you
know
get
from
reflection
api
because
we
weren't
implicitly
keeping
around
all
these
other
serializers,
would
would
that
kind
of
be
a
middle
ground?
B
B
Yeah,
okay,
yeah,
so
we
don't
know
what
the
type
is
we
wrote.
All
of
them
might
like.
We
wrote
all
of
them
and
then
look
through
to
see
whether
any
of
them
like
match
with
the
type.
I'm
not
sure
that
the
implementation
for
these
new
suggested
methods
could
do
something
different
unless
it's
code
gen
somehow.
B
And
then
put
the
cogen
stuff.
Is
the
existence
of
what
are
you
proposing?
So
I
don't
know
that
the
implementation
for
those
type
of
two
methods
could
do
it
without
rooting
things,
because
it
could
be
one
it
could
be
because
he
still,
if
checks
right
to
see
if
it's
this
type
then
do
that.
So
I
don't
know
that
it
helps,
but
I
can
look
at
it,
but
my
feeling
is
that
everything
will
still
be
rooted.
B
E
Because
it's
a
stepping
stone
right,
it's
like
you,
can't
make
the
big
you
can't
make
it
all
in
one.
You
can't
go
from.
You
have
an
existing
app
that
calls
serialize
all
over
the
place
and
you
can
only
use
source
gen
for
three
out
of
the
ten
places,
and
so
you
try
making
a
context
everywhere.
But
since
you
can't
get
source
gen,
then
you
have
this.
Oh,
let
me
fall
back
to
the
reflection
case
right.
That's
the
that's
the
scenario
here
so.
G
All
of
these
controllers
to
find
out
what
things
can
be
bound
for
input
and
for
output.
I
can
see
us
actually
calling
this
api
and
stashing
it
once
per
our
our
watts
per
controller.
Almost
for
action,
I
mean
we
call
serialize.
We
we
have
that
mission
in
our
hand
and
we
can
just
pass
it
into
serialization,
avoiding
any
kind
of
of
look
up
there
as
well.
B
So
in
that
case,
it's
your
it's,
not
the
serializer.
That's
calling
these
methods
it's
in,
not
just
that
case,
but
in
any
case
the
user
will
do
it
to
populate
their
json
context
and
then
but
okay,
so
how
do
they
in
their
get
type
info
method?
Do
they
hard
code,
the
the
new
stuff
in
there
or
it's
part
of
the
implementation
like?
If
it's
not
one
of
these
types,
I
I
know
it's
in
there
then,
like
you,
know,
generate
the
new
thing
and
then
return
it
crash.
It
is
that.
B
D
B
D
M
H
A
C
G
C
B
C
A
So
if
we
actually
just
made
that
be
the
way
that
you
did
the
lookup
from
for
the
type
on
the
on
the
options
class,
then
I
mean
it
may
be
changing
all
of
your
plumbing.
But
conceptually
you
could
make
this
new
method
that
I
wrote
a
notepad
just
call
into
the
cache
inside
the
options
type
right.
So
I
think.
B
The
implementation
today
would
awkward
when
you
first
get
typing
for
crash,
that
in
the
options
instance
so
that
you
know
it
knows
it
has
that
the
type
so
that
okay,
so
that's
all
so.
C
So
this
this
gets
to
one
of
the
comments
that
steve
had
made.
I
think
tuesday
was
that
for
really
hot
path
scenarios
the
dictionary
hit
is
actually
showing
up
in
measurements.
So
if
this
doesn't
use
the
cache,
does
that
then
mean
that
using
the
new
overloads
with
this
api
actually
gives
you
a
perf
benefit,
because
you
can
call
this
once
cache
it
and
then
always
pass
that
same
one
in
without
having
to
go
through
a
dictionary.
I
really
hope.
O
C
It's
probably
I
mean
I
don't
know
the
implementation
of
jason
type
info,
so
you
guys
that
know
the
implementation
can
say
whether
this
would
actually
be
a
problem
or
whether
it
would
just
change
where
we
did
certain
checks,
but
for
hot
reload
we're
talking
about
how
we
need
to
clear
caches
when
a
notification
is
received,
how
I
had
proposed
doing
that
hand
wavy
for
jason,
serializer
was
have
a
static
version.
Number
that's
incremented
any
time.
There's
a
notification
and
the
json
serializer
options
would
have
a
version
number
on
it.
C
That
was
snapped
basically
to
say
like
as
long
as
this
version
number
is
the
same
as
the
global
one.
Your
cache
is
valid
and
that
would
show
up
in
the
get
or
add
method
or
whatever.
That
method
is
called
inside
of
json
serializer
options
where,
before
the
dictionary
lookup,
it
would
basically
say
if
s
you
know,
underscore
version
does
not
equal
underscore
current
version,
clear
cache.
C
This
api
works
around
that
because
it's
never
checking
that
cache,
which
would
mean
that
any
kind
of
clearing
would
have
to
be
done
inside
of
json
type
info,
and
I
don't
know
what
that.
Well,
how
is
source
gen
going
to
work
in
this
at
all
on
high
school?
If
you
make
a
change
to
the
type,
it
should
be
regenerated.
E
C
C
The
default
instance
say:
oh
no,
throw
away
all
my
type
info
what's
happening,
but
apparently
that's
not
what's
happening,
so
it
wouldn't
work.
If
you
were
actually
holding
on
to
that
instance
such
that
that
instance
wasn't
getting
recreated
right.
A
C
A
C
B
A
Yeah,
if
it
re-ran,
if
you
changed
a
class
that
you
had
said,
you
want
to
be
json
serializable,
you
change
something
so
edit
and
continue
would
rerun
the
source
generators
which
would
redefine
what
your
json
context
type
look
like.
I
don't
know
if
that's
going
to
immediately
throw
away
any
static
instances
or
not,
because
I
don't
know
how
patching
types
works
but
assume
it
doesn't.
As
long
as
this
thing
checks
for
the
have
I
been
hot
reloaded,
the
default
can
then
just
re-instantiate
the
type
which
will
get
the
new
definition,
which
has
the
new.
C
C
O
So
is
the
source
generator.
Is
this
a
production
scenario
or
just
like
a
design
time
development
scenario?
Yeah,
you
know,
watch
control,
f5
or
f5,
okay,
so
in
production
environment
there's
going
to
be
a
capability
running,
I
mean
rosalind
and
whatever
I
mean
it
has
to
be
right
in
production.
What
do
you
mean
by
production?
I
mean
you
you're,
not
in
development
mode.
You
published
it
to
a
real
server
and
your
and
your
you
know
clients
are
hidden
at
real
time.
No.
O
B
Okay-
and
I
have
I
have
an
actual
item
to
test
this
out
I'll
just
say,
but
like
even
before
this
meeting.
That
was
something
I
wanted
to
look
into.
C
A
Well,
this
the
you
know
the
create
type
info
via
reflection
that
I
made
up
on
the
spot
during
this
meeting
it
can
we
we
control
the
type
info
it
returns
it
can
set
up.
It
could
use
the
global
counter
bit
and
say
I
was
created
via
reflection
from
this
library,
not
via
custom,
create
it
could
go
mark
itself
or
go
rescan
via
reflection
and
rebuild
it
like.
We
can
do
dirty.
C
A
Right
so
I'm
just
like
this
could
be
special,
but
we
can't
make
the
one
that-
or
we
can't
necessarily
make
the
type
be
special,
because
if
you
just
created
one
by
saying
jason
type
info
of
t
dot
create
and
gave
it
all
the
property
like
all
the
callbacks,
it
needs
to
do
all
the
stuff
like
there's
nothing
to
bind
to
on
that.
You
built
it
out
of
nothing.
C
A
C
B
Yeah
question
options:
yeah
the
property
that
returns
the
options
associated
with
context.
It's
nullable
because
there's
a
state
where
it
is
not
bound
to
an
options.
Instance
a
protected
constructor
for
when
you
create
an
unbound
context,
instance
another
one.
We
take
an
optional
instance
for
when
you
pass
an
option
instance
initially
proposed
get
type
in
four
returns,
an
elbow
type.
B
It
could
return
null
if
you
ask
it
for
a
type
he
doesn't
know
about.
I
think
you
shouldn't
throw
an
exception.
Here,
got
a
request
for
generic
version.
I
still
haven't
followed
up
on
how
the
implementation
can
be
better,
and
things
like
that.
So
I
have
this
sort
of
conditional
for
now.
B
I
imagine.
Maybe
we
only
did
the
second
one
if
we
can
have
a
more
optimized
implementation
for
it
and
not
the
first
one.
B
A
A
A
Like
maybe
we
define
the
generic
one
that
you
have
to
go
implement
that
yourself
and
we
make
the
non-generic
one
just
call
the
generic
one,
and
now,
if
you
make
a
sub-optimal
generic
one,
that
was
up
to
you,
but
I
don't
think
we
want
both
of
them
to
be
virtual.
A
A
A
G
E
C
A
F
A
So
I
guess
that
this
is
this
is
a
new
world
for
us
with
generated
code
right.
If
this
was
if
this
was,
we
think
that
we
can
have
a
tool
that
spits
some
stuff
out
and
generated
codes,
not
part
of
an
official
build
or
an
official
concept
or
anything.
We
would
just
say
you
have
two
virtuals
that
can
get
out
of
sync.
What
like
this
doesn't
make
sense.
F
A
Well,
but
then
you're
now
back
to
the
our
our
sad
state
of
you
need
to
remember
to
override
both
to
do
the
delegation
on
both
because
complexities
like
if
you
wrote
my
my
other
notepad
this
guy,
you
have
to
write
both
versions
of
this
for
loop.
A
A
F
I
think
it's
a
it's
a
very
specific
case
right,
because
the
whole
point
of
the
generator
is
to
lift
the
type
system
into
the
code
right,
and
so
this
is
an
example
where
you
have
a
dynamic
type
system
and
in
terms
of
system
type,
and
you
have
the
static
generic
right,
so
it
seems
I
can
see
for
generator
cases
when
that
pattern
actually
will
be
popular
you'll
even
need
to
handle
both
cases.
Yeah
yeah,
I
just
said
one
con-
call.
F
P
G
E
G
Do
it
in
do
it
in
preview?
Five,
that's
fine!.
F
So
I
guess
my
other
question:
is
you
like
that?
So
earlier,
like
you
said,
there's
a
state
where
options
is
now.
How
do
I
observe
that
state
because
it
seems
like
default,
constructor
will
clone
one
and
the
other
one
takes
one.
So.
B
Oh
sorry,
sorry,
the
cloning
cloning
comment
doesn't
apply.
Anymore.
Comments
are
not
cl.
The
options
are
not
cloned.
So
when
it's
not
knowledge,
I
mean
when
the
options
are
knowledge,
when
the
context
is
not
bound
and
we
want
to
set
the
context.
A
Yeah
I
mean,
if
yeah,
if
the
just
thinking
things
out
loud,
if
we
do
the
the
generic
version
and
we
don't
let
it
take
an
instance,
you
can
completely
hide
this
state
and
just
this
could
be
get
private
set
on
the
options
and
you
called
json
serializer
options
that
add
context
of
t.
It
says
new
t
which
thinks
it's
using
the
default
options
and
then
you
go.
You
have
different
options
now,
but
because
I'm
all
the
same
library,
I
know
it's
totally
safe
to
replace
them,
because
I
haven't
called
any
of
the
members
yet.
A
B
A
A
A
F
A
The
individual
json
context
classes,
because
this
is
the
base
class.
The
individual
classes
would
have
a
default
constructor
that
uses
the
default
options
or
the
null
options,
or
you
know
whatever,
but
that
generic
method
will
call
new
paren
print,
which
works.
No
one
has
read
the
options
property
yet
so
no
one
cares.
If
it's
observed
to
be
in
in
a
was
pre-assigned
or
is
going
to
auto-assign
itself
as
default
and
then
being
inside
the
library.
E
E
E
C
B
All
right,
okay,
so
all
right
so,
and
so
that
means
this
is
totalization.
This
one
is
civilization
metadata
because
it
represents
type
metadata.
B
So
the
first
one
is
the
adjacent
type
info
internal
parameters
constructor
so
that
people
can't
derive
from
it
actually
knew
of
instances
of
this
like
internally
in
system
technicians.
So
that's
why
it's
not
abstract!
It
has
a
public
converter
property
that
is
needed
in
the
generated
code
so
that
they
can
get
converters
for
like
the
different
types
they
have
in
the
object
graph.
B
The
next
thing
is
abstract
descent
type,
the
converter,
no,
the
converter
should
not.
You
know
if
if
we
can
fetch
it
or
create
a
converter
for
type,
we
throw
not
supported
exception
today.
So
it's
the
same
behavior
here
so.
F
A
B
Yeah,
the
internal,
like
infrastructure
methods
I
have
below
assign
converters
to
those
types
for
the
like
object
and
collection
cases
for
primitives.
We
expect
them
directly,
no.
A
B
E
B
Yeah
I
forget,
but
I
do
know
I
need
it
certainly.
O
O
B
I'm
very
fine,
it
could
be
that
it
just
needs
to
be
internal
and
we
refer
to
it,
but
I
I
think
I
remember
having
to
reference
it
in
the
generator
code
itself.
O
B
B
F
A
B
E
A
B
F
Yeah,
I
think
to
me
the
only
argument
for
exposing
the
options
this,
so
I
only
have
to
hold
on
to
one
of
them,
because
it
seems
weird
if
I
have
to
stash
the
options
and
the
contacts.
If,
if
I
get
a
because
I
mean
it
seems
like
there
will
always
be
these
two
kinds
of
apis,
one
that
takes
options,
one
takes
context,
so
I
it
seems
like
I
need
both
of
them
right.
A
F
E
F
J
E
F
B
F
Yeah
I
say
yeah,
my
question
is
more
like:
does
it
matter
how
it
got
constructed
right?
Because
if
I
know
I
have
a
better
forecast
somewhere,
I
you
know,
can
I
always
say
jason
type
info,
better
forecast
and
don't
constant.
The
answer
seems
to
be
yes.
I
mean
it
also
doesn't
really
seem
to
matter
right
because
I
mean
so
there's
nothing
on
json
type
info.
That
would
matter.
So
why
does
this
type
have
to
be
public.
B
Yet
so
one
two
things
that
it
does,
it
allows
you
to
not
have
to
specify
the
generic
parameter
to
do
to
the
serializer
method.
You're
calling
the
other
thing
is.
This
is
where
we
would
put
the
serialized
object,
fast
path
when
we
get
to
that
later
and
for
pv5.
Hopefully,.
B
A
F
B
And
yeah
as
overloads
as
an
input
system
and
also
when
you
want
to
have
fast
part
stuff
to
deserialize
or
serialize
dt,
because.
A
E
B
B
O
B
C
B
Yeah,
we
need
to
reflect
everything
like
so
we
have
this
hierarchy
to
support
like
different
type
infos
for
because
we're
generating
code
for
user
stuff,
but
we
didn't
need
to
do
any
of
that
like
prior
before
with
this
effort.
So
everything
was
just
like
creating
new
type
info,
and
so
we
can
refactor
stuff
internally
to
make
this
abstract.
A
Yeah
I
mean
at
the
end
of
the
day
it
really
as
long
as
there
are
no
public
or
protected
constructors.
It
really
doesn't
matter
if
it
says
abstract
or
not.
You
can't
instantiate
the
type.
So
it's
just
it
looks
weird
in
the
in
the
metadata
that.
F
A
B
So
there's
no.
B
Yeah,
so,
as
far
as
as
far
as
the
gen
code
is
web
methods
help
you
create
instances
of
those,
but
users
don't
need
to
create
them.
A
K
C
F
A
The
gen,
I
think
it's
the
generator,
we'll
call,
because
this
is
compiler
or
this
is
the
generator
metadata
thing
right.
So
the
generator
calls
metadata
services
create
property
info
with
all
the
details,
it
gets
back
an
opaque
object
that
it
then
just
passes
into
this
other
thing.
So
this
is
the
I
need
to
give
you
a
handle.
You
don't
need
you
don't
get
to
ask
any
questions
about
it.
J
E
B
A
O
O
You
want
to
have
terminology
in
our
source
code,
I
mean
you
know,
do
you
want
to
say
this
is
adjacent
property
or
this
is
an
abstraction
of
a
clr
property
or
slash
number.
B
B
A
B
B
F
I
mean
honestly
like
I
would
be
okay
with
doing
what
they
only
suggested
because
realistically,
when
you
have
a
generator,
you
can
also
raise
diagnostics
and
we
can
just
completely
fail
the
build.
If
you
apply
this
attribute
at
the
assembly
level,
don't
pass
the
type
or
you
apply
it
at
the
type
level
and
do
positive
type.
I
mean
we
can.
We
don't
have
to
handle
that
you
know
in
weird
ways
we
could
make
it
actionable,
but
we
can
also
start
with
saying
that
syntactic
sugar,
so
you
don't
get
to
do
that.
F
F
A
List,
so
do
we
do
we
I
mean,
do
we
want
to
say
that
it's
attribute
targets
or
assembly
class
instruct
or.
A
A
G
F
D
D
F
There's
no
documentation
right
if
the
type
doesn't
exist
anywhere.
We
can't
document
it
really
easily
right
so
that
you
end
them
in
these
weird
half
states
a
level
attribute.
Nobody
cares.
It
doesn't
have
to
be
documented
because
it's
purely
infrastructure
for
the
compiler,
so
yeah
we
didn't
ship
that
one.
A
F
I
mean
we
can
I
mean
it
seems
like
there's
a
meeting
next
week
that
somebody,
I
think
aaron
forwarded
me
to
this,
that
that
we
should
talk
about
this,
but
I
think
there
is
there's
experience
issues
if
we
don't
make
it
a
bcl
type.
Okay,.
A
Q
E
Q
C
F
A
Yeah
I
feel
like
I
was
in
fact
a
metoor
on
that
one.
So.
A
F
M
F
I
think
my
recommendation
would
be
like
it
seems.
The
attribute
should
be
in
serialization,
because
users
generally
don't
want
to
use
json
type
info
or
type
property
info,
that's
just
for
the
generator
itself,
but
they
do
want
to
reference
that
attribute
from
user
code.
So
I
would
put
everything:
that's
user
code,
basically
in
the
existing
name,
spaces,
which
is
either
system
text
or
json
system
text
or
json
serialization,
and
then
I
would
probably
have
just
one
name
space
for
the
generator.
So
I
would
probably
collapse
the
metadata
and
the
metadata
internal
one
into
one.
F
I
probably
wouldn't
use
internal.
I
would
just
live
with
the
fact
that
we
have
one
type
in
there
that
you
say
it
is
never
and
that's
good
enough,
because
I
mean
internal
is
weird
anyway,
because
as
the
tower
experience
the
hard
way,
it's
like
you
can
put
this
all
day
long
there,
but
you
can't
make
breaking
changes
the
either
way.
So
it's
yup.
B
So
just
leave
it
internal
and
rely
on
your
editor,
but
never
or
come.
Each
is
a
difference
of
like
a
name.
F
B
Yeah,
you
can
imagine
features
where
people
want
to
programmatically
like
set
metadata
for
their
types
and
that's
how
I
started
thinking
about
this
early
like
at
first
yeah,
but
it's
kind
of
risky
because
it
restricts
us
like
we.
If
I
expose
the
shape
of
the
type,
then
we
can't
it's
harder
to
change
things,
not
that
we
can
change
things
really
with
this.
But
it's
nicer.
A
I
mean,
I
think
metadata
is
fine,
because
the
the
namespace
will
show
up
on
like
apisof.net,
because
that's
that's
where
json
type
info
of
t
will
live
and
metadata
seems
better
than
generation
generation
is
the
purpose
we
added
it
for
metadata
is
the
role
it
serves.
It's
like
calling
it
type
extensions
which
we
said.
That's
why
you
added
it,
but
that
instead
described
the
purpose
it
serves.
E
A
A
B
Okay,
so
these
are
methods
that
create
these
metadata
instances.
The
first
one
create
value
info
of
t.
It
will
yes,
statistics
and
options
on
the
converter
for
your
type
and
it
returns
the
typing
for.
Q
B
B
Yeah,
we
just
need
to
know
what
the
t,
what
returning
is,
because
we
need
to
assign
it
to
a
property
of
it
typing
for
property.
B
B
A
B
So
jason
object
of.
Can
we
proceed.
A
E
B
A
B
Initialize
object
of
t
takes
the
type
in
full
generic,
because
today
we
expect
it
to
be
that
he
so
it
provides
a
little
validation
there.
We
need
the
options,
then
we
take
a
funk
that
creates
an
instance
of
the
tea.
That's
a
parameter-less
constructor
later
on
I'll
bring
another
api
that
supports
a
parameterized
constructor.
B
So
I
just
wanted
to
note
initially
I
had
this
as
like
delegate
like
where
it
returns
an
object
and
no
parameters.
B
B
So
maybe
you
just
express
it
as
a
func
still.
I
just
wanted
to
note
that
that's
the
third
parameter
of
initialize
object.
A
I
mean
that's,
that's
going
to
be
true
like
if
we
want
to
make
the
parameterized
constructor
and
the
parameter
list.
Constructor
use
the
exact
same
call
path
that
would
yeah
basically
be
funk
of
innumerable
of
object
or
object
bracket
bracket
to
t
it
seems
like
the
case
where
you
are
default.
We
can
do
the
nicety
of
just
funk
of
t
and
avoid
the
complex
parameter,
ignoring.
B
Still
kind
thinking,
but
you
define
your
your
funk
and
the
phone
could
take
an
object
array
and
it
will
unbox
those
and
then
pass
it
to
their
constructor.
B
The
permit
the
permit
parameters,
one
that
we
can
call.
E
B
E
B
E
B
O
A
A
E
B
No,
this
is
the
only
one
for
there's
no
other
like
attribute
on
what
is
the
converter.
I
think
that's
represented.
So
much
should.
A
A
A
B
B
Should
mean
nothing
was
specified,
I,
and
that
was
my
reason
about
it
before,
but
then,
if
and
that
should
because.
A
F
Yes,
that
naomi's
engine
will
basically
make
the
determination
and
pass
you
either
the
one
that
was
applied
or
the
options
run.
But
by
the
time
your
code
runs
like
it's
clear
which
one
to
use,
because
there's
always
one
answer
right
either
the
one
that
you
put
on
the
attribute
or
is
the
one
from
the
options.
A
Yeah,
if
the
generator
can,
I
guess
the
generator
can
see
the
options
because
it
passed
it
as
the
second
parameter.
So
I
guess
the
generator.
If
you
didn't
have
it
on
the
property,
it
could
call
options.default
number
handling
and
just
pass
that
here,
which
is
all
that
the
method
internal
is
going
to
do
so.
I
guess
the
generator
can
figure
out
the
right
value
to
pass
yeah
and
then
this
is
the
answer
because
it
was
either
specified
or
it
came
from
the
options,
but
the
generator
knew
the
answer
and
wrote
it
down.
Okay,.
F
Well,
it
would
have
been
something
like
you
know
the
effective
options
or
something
right.
I
mean
I
guess
we
could
say
that
for
every
option
that
you
can
do
locally,
there's
a
global
one,
so
we
can
always
reuse
json,
serializer
options
and
worst
case
we
assigned
to
it.
But
that
seems
unfortunate,
given
that
that
options
has
cash
has
a
cash
right,
because
you
better
get
that
cash
every
time
you
do
that.
E
A
F
B
Yeah
those
those
ones
are
not
about
features,
that's
like
we
need
to.
We
need
them.
The
number
ignore
condition
number
handling
are
about
features.
So
it's
just
two
right
now,
but
yeah.
B
Add
more
of
these
like
for
more
features
in
the
future,
so
if
we
had
like
a
type
that
housed
all
these
things
some
class,
what
could
we
call
it.
A
Yeah
I
mean
the
the
because
the
problem,
if
we
made
a
thing
that
took
these
11
things,
we
would
call
it
something
like
json
property
info
and
then
we'd
need
a
way
for
you
to
build
it,
which
would
be
a
constructor
or
a
method
that
took
this
many
parameters.
And
this
is
that,
like
this
is
the
garbage.
F
E
C
A
Well,
it
handles
things
like
if
you
left
the
bmp
it
has
to
do
backslash.
U,
like
it,
has
to
do
the
utf
encoding
of
backslash?
U
whatever,
whatever
whatever
so
it's
it's,
not
just
utf-8
string.
E
Q
B
Oh
t,
collection
is
anything
that
derives
from
list
in
this
case
and
for
the
dictionary
one
anything
there
are
some
dictionary
of
the
key
effects
value,
so
I'll
will
be
so
this
is
one
strategy
I
will
be
bringing
more
to
support
the
other
collection
types.
Next
preview.
B
B
A
A
B
A
F
B
B
O
A
B
F
I
guess
it
depends
on
how
you
want
to
expose
it,
but
I
would
think
that
if
people
actually
derive
they're,
not
gonna,
say
deriving
from
list
or
dictionary,
they
usually
derive
from
you
know,
collection
of
tea
or
with
only
collection
of
tea
or
whatever
the
dictionary
equivalent
of
that
one
was.
I
forgot,
like
it's
key
key
collection
or
something
like
that,
and
then
list
list
is
usually
used
by
itself
until
dictionary
right.
So
I
I
that's.
Why.
F
Suggesting,
if
you
do
I
list
my
dictionary,
you
basically
have
99
of
collection
types
that
people
would
will
actually
use
in
practice
like
you're,
not
very
likely
having
to
extend
that.
But
I
guess
I'm
not
entirely
sure
what
you
mean
by
perfect.
If
it's
because
like
are
you
saying,
you
have
different
implementations
for
a
dictionary
in
my
dictionary.
B
Yes,
I
just
posted
in
the
chat
like
the
list
of
all
the
converters
that
we
have
to
handle
collection.
F
B
Yeah,
I'm
hoping
that
we
don't
have
to
add
another
feature.
Even
number
handling
could
have
been
implemented
as
a
converter.
Quite
honestly,
so
we
don't
have
to
pass
it
around,
but
I'm
hoping
that
once
we
have
these
collection
types,
we
don't
need
to
add
more
variations
of
them.
We
just
need
typing
for
the
key
type
or
the
the
value
type
or
you
know
typing
for
the
element
type
and
I
think
that's
all
the
information
would
ever
need.
B
B
A
B
F
Yeah,
so
I
think
that's
fair
if
you,
if,
if
you
want
to
say
I
wanna,
I
wanna
have
a
way
how
I
can
tell
the
linker
that
they're
using
I
dictionary
versus
dictionary,
then,
yes,
you
need
different
methods
and
all
I'm
saying
is
you
can't
overload
so
that
just
means,
if
you
want
to
add
a
dictionary
later,
the
method
has
to
be
called
create.
I
dictionary.
F
A
A
The
whatever
the
serializer
supports
in
terms
of
these
implicit,
the
interfaces
that
determine
the
way
that
you're
going
to
change
the
serialization
somebody
needs
to
be
able
to
express
this
with
the
generator.
So
basically
you
want
the
the
the.
If
you
want
to
distinguish
between
dictionary-
and
I
dictionary
I
dictionary-
is
more
important
because
it's
more
users
and
dictionaries
more
important.
So
you
have
to
do
both
of
them
right
now
or
you're,
cutting
off
preview
for
feedback.
A
A
B
E
B
E
F
Well,
I
think
clr
is
a
bit
specific
I'll
give
you
that
I
think
in
in
rosman.
That's
also
there
it
wasn't.
They
have
apis
like
where
you
can
look
up
types
of
metadata
name,
which
means
you
have
to
use
the
backtick
one.
Take
two
syntax,
for
example.
Generic
types
any
in
this
case
metadata
is
unfortunate,
because
this
whole
thing
is
metadata,
so
it
might
be
a
bit
deleting.
K
Q
E
E
I
L
Was
just
discussed
on
discord
the
cyrus
language
runtime.
F
F
E
E
B
F
E
F
F
A
M
B
A
Yeah,
so
the
feedback
that
I've
given
in
private
is
we
could
put
these
if
we
wanted
them
to
be
public
on
the
non-generic
json
converter.
But
I
don't
I
don't
care
I
just
seeing
if
anyone
else
cares.
B
F
F
B
A
F
F
Don't
personally
care
what
you
design
a
use
case
right
if
the
use
case
is
entirely
always
effectively
within
the
generated
code,
then
I
think
merging
the
metadata
services
makes
sense
if
you
think
that
there
are
other
eligibility
skills
where
you
just
want
to
get
the
converter.
For
short,
let's
say
then
pulling
them
aesthetics
and
json
converter
probably
makes
more
sense.
B
A
And
because
why
go
only
forward
when
we
can
also
go
back
to
return
to
clr
property
name?
There
was
some
youtube
chat,
suggestion
of
member
name
that
way
it
also
encompassed
fields.
A
Well,
but
we
said,
property
was
fine
because
it's
describing
a
json
property,
but
once
the
clr
data
item
is
a
property
or
a
field
and
calling
it
member
name,
avoids
the
json
property
versus
property.
Name
like
I
think
it's
a
reasonable
suggestion.
I
don't.
I
can
add
it
to
the
list
of
things
for
leo
me
to
consider
or
we
cannot.
A
Q
B
A
A
It
just
puts
fewer
things
in
people's
faces
when
they're
writing
their
own
converter,
because
when
you're
writing,
if
you're
writing
your
own
converter,
all
the
statics
would
show
up
right.
So
it's
like!
Oh,
do
you
want
to
talk
about
or
which
uint16
do
you
want
at
this
point?
In
fact,
that
would
actually
be
ambiguous
for
like
good.
In
fact,
it
would
prefer
the
property.
I
think.
B
Yeah
yep,
the
first
trunk,
is
new
overloads
that
we've
been
talking
about,
but
jason
sterilizer
and
as.
K
B
K
B
Methods
and
distance
serializer
basically
multiply
to
take
all
the
overloads
multiply
by
two
wherever
we
are
passing
a
type.
We
pass
the
context
whenever
we
use
the
generic
t,
we
pass
the
type
info
and
then
next
are
the
systematic
json
methods
overload.
So
that's
similar
thing,
I
think,
there's
some
cases
where
the
options
are
not
passed
in
those
apis,
so
those
ones
and
they
don't
have
a
replicate
here.
I
assume
the
I
think
didn't
resume
the
default
options
in
that
in
those
cases,
but
wherever
we
did
pass,
options
multiply.
B
Take
that
and
then
wave
we
pass.
It
type
take
the
context
where
we
pass
dt
take
the
type
info.
A
A
A
E
E
B
A
B
Also,
there's
a
bit
of
a
perf
hit
because
we'll
have
to
call
get
class
typing
typing
for
type
type.
In
that
case,.
E
E
M
A
A
E
E
B
E
A
Okay,
I
have
a
giant
set
of
notes.
A
A
A
Well,
typically,
when
you
only
have
like
three
suggestions
on
things,
you
take
the
proposal
and
like
make
the
three
suggestions
and
then
paste
it.
But
there's
a
lot
of
suggestions
here
and
I'm
lazy.
K
F
A
L
F
No,
I
can
my
face,
probably
says
the
same
thing.
So
then.
The
only
thing
I
want
to
say
is:
like
I
mean
we
spend
a
lot
of
time
talking
about
this.
I
hope
that
neither
leon
or
steve
feel
like
we're
just
you
know,
second,
guessing
them
or
not
picking
on
everything,
but
it's
one
of
the
most
complicated
thing
we
have
built
next
to
the
serializer
in
quite
a
while.
It's
you
know
so
it's
I
think
we
all
want
to
get
it
right
and
there's
lots
of
lots
of
unknowns.
F
Lots
of
new
user
experience,
details
that
we
need
to
figure
out
and
I'm
pretty
sure
like
once
we
ship
preview,
four,
we
will
get
even
more
feedback
that
we
haven't
even
thought
about
yet
so
it's
good.
A
Mean
yeah,
it
just
happens
to
be
the
very
complicated
we're
working
on
the
linking
features,
so
we
want
to
make
sure
it
works
with
that.
This
is
our
really
our
first
generator,
so
we're
inventing
precedent
here,
instead
of
depending
on
it
so
yeah,
yes
to
restate
emo's
thing,
we're
not
picking
on
you
we're
we're
making
sure
that
we
know
what
to
do
for
the
next
generator.
O
And,
and
as
a
plan
of
action,
ammo
are
you
thinking
for
other
blocked
features
that
are
trying
to
get
a
preview
for
that
we
hold
someone
off
meetings
or
your
thoughts,
so
that
was
the.
F
That
was
the
only
one
I
was
aware
of.
I
mean
in
general,
like
you
know,
we
previously
have
a
fairly
low
bar
in
terms
of
breaking
changes
right
now.
The
the
the
only
thing
we
need
to
keep
in
mind
is
that
pv4
is
the
you
know:
quote-unquote
build
build,
even
though
you
know
build
is
not
an
in-person
event
is
really
the
most
hyped
version
of
our
stack.
F
So
that's
usually
where
you
get
most
of
the
customer
adoption,
meaning
you
know,
preview
five
and
six
people
will
not
upgrade
as
much
to
those
as
they
do
to
preview
four,
so
anything
that
doesn't
make
it
into
preview
4.
You
will
just
get
less
feedback
on
that's
pretty
much
all
it
means
it
doesn't
mean
you
don't
get
to
ship
it
right.
I.
O
Mean
just
for
my
own
benefit,
I
was
talking
mostly
about
the
writable
dom.
F
O
H
I
think
the
strongly
typed
I
logger
messages
is
in
a
similar
boat.
This
is
another
source
generator
where
it's
pretty
important
for
us
to
get
feedback
by
a
large
number
of
people.
So
I,
if
there's
a
way
to
promote
that
one
as
well.
I
would
it's
the
first
one
right,
that's
correct!.
F
H
I
think
I
think
we
have
pretty
high
confidence
that
the
the
dom
is,
you
know
nearly
done
with
feedback.
I
suspect.
Let
me
press
the
record
button,
so
I
can
play
through
tomorrow
morning,
but
yeah.
H
Okay,
so
the
logging
source
generator
is
kind
of
a
new
type
of
generator.
I
I
don't
know
how
much
you
guys
have
gone
over
it
so
far,
but
I
expect
that
there'll
be
some
more
precedent
setting
there
so.
F
A
Okay,
but
we
will
only
do
these
two
things
and
then
we'll
just
give
people
time
back.
F
Then
I'll
book,
the
meeting
for
tomorrow
morning,
probably
10
to
12
because
it's
the
usual
slot
and
then
after
that,
it's
weekend
time.
A
Okay,
don't
yeah
make
sure
you're
not
booking
too
many
solid
hours
of
meetings.
In
fact,
you
already
don't
have
10
to
12
email.
F
B
Something
I
have
a,
I
have
a
question,
so
I
mean
I
totally
understand.
If
this
is
not
api
approves
level
yet,
but
is
it
was
intentional
not
to
put
that
level.
A
I
was
going
to
ask
emo:
should
we
label
this
as
anything
or
is
because
it
sort
of
feels
like
the
answer?
Is?
We've
talked
about
some
things,
it's
going
to
go
in
preview,
for
we
know
they're
going
to
be
changes.
It's
not
the
final
shape,
and
this
is
probably
still
needs
work,
but
needs
work
with
good
enough
for
prototype,
which
means.
F
F
If
you
want
to
do
this
here,
I'm
also
fine,
with
marking
this
api
approved
and
then
file
a
secondary
issue
with
basically
just
as
a
tracking
issue
of
saying,
please
incorporate
feedback
or
whatever,
so
we
don't
forget
about
it,
but
it
also
doesn't
seem
like
you
will
forget
it,
so
people
will
kick
in
our
door,
so
I
I'm
fine
either
way.
E
A
A
All
right,
so
I
think,
with
that
we're
gonna
wrap
at
least
I'm
gonna
cut
off
the
stream,
and
I'm
gonna
drop
off
the
call
and
I'll
let
the
rest
of
these
guys
do
whatever
they
want.