►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello,
hello,
everyone
happy
new
year.
This
is
our
first
api
review
since
I
think
early
december
because
we
lost
quorum.
I
think
pretty
much
in
the
beginning
of
december,
so
a
few
issues
have
piled
up
now
we
have
27.
Hopefully
we
get
through
the
top
10
today
and
let
me
just
open
a
few
here
up.
It's
a
bit
easier.
B
B
Sorry,
that's
a
typo,
it
should
have
been
queryable.
I
think
I.
B
C
E
C
sharp
tuples
stop
at
seven.
So
that's
one
way
to
decide
framework
design
guidelines
stop.
G
C
C
Yeah
I
mean
I
used
link
quite
a
lot
in
a
previous
life.
I
think
I
would
and
would
have
had
a
use
for
three
arguments.
I
don't
know
if
I've
ever
used
or
needed
more
than
three.
F
Yeah
I
mean
during
advent
of
code,
I
did
use
probably
some
triplets,
but
you
know
not
from
something
like
enumerable.zip.
It
was
just
a
you
know,
list
of
triplets
but
yeah,
so
either
we
can
do
three
because
that's
where
the
guidelines
stop
or
we
can
do
four,
because
we
don't
think
anyone
will
need
it
and
it'll
should
we
should
never
hear
a.
C
C
Just
to
play
devil's
advocate
here,
not
many
people
need
this.
Is
it
worth
adding.
E
G
C
A
H
E
Using
yeah
I
mean
there's
a
there's,
a
legitimate
point
that
maybe
the
code
gen
could
be
more
efficient,
but
I
don't
think
it's
it's
a.
H
A
This
one
only
does
the
tuple
one
right
should
we
also
have
the
action
one?
Does
it
take
more
arguments
already
or
how
does
that.
A
E
So
there's
some
like
controversy
about
the
design,
so
I'm
gonna
have
to
lean
on
you
a
bit
for
knowledge
about
the
platform
analysis
system,
stuff,
the
capability
and
analyze
analyzers.
E
So
the
the
basic
idea
is
that
we
want
some
way
to
mark
that
some
api
is
not
compatible
with
the
single
file
published
stuff
that
we
introduced,
because
we
no
longer
extract
to
disk
certain
operations
just
aren't
possible
the
primary
one
being
assembly.location
right
now
we
have
an
analyzer
that
shipped
in.net
5,
that
if
you
have
the
publish,
trimmed
property
set
to
true
it
runs,
and
then
it
warns
on
every
single
use
of
assembly.location
saying
you
know
unless
you're
absolutely
certain
that
you
loaded
this
dll
from
something
like
assembly.load
from
this,
probably
is
not
going
to
return
something
useful.
E
The
goal
is
that
we
would
like
first
to
get
the
ability
for
other
users
to
mark
things
as
being
not
safe
to
use
an
assembly.
Sorry
in
single
file
and
we'd
also
like
to
reduce
some
of
the
burden
of
like
a
handwritten
analyzer
a
little
bit
by
being
able
to
turn
it
into
a
single
attribute
that
we
put
everywhere.
A
A
E
I
was
thinking
about
that
last
night.
The
problem
is
that
there's
really,
we
could
actually
break
this
out
into
two
separate
things.
There's
the
question
of.
Does
this?
Does
an
assembly
have
a
location
that
is,
does
it
exist
on
disk
or
not
and
there's
a
question
of?
Are
we
using
single
file
mode,
which
is
probably
approximately
like,
is
corelib?
This
core
live
exist
on
disk
right,
the
the
first.
Does
this
assembly
exist
on
disk
or
not
is
an
existing
thing
that
we've
always
had?
E
You
can
load
well,
not
always,
but
you
you've
been
able
to
load
assemblies
from
memory
for
a
very
long
time.
It's
reasonable
to
ask.
Is
there
a
capability
here
like
we
could
add
a
new
api
right
now,
the
way
that
people
check
to
see
whether
an
assembly
is
loaded
from
memory
is
grab?
The
assembly
object,
do
assembly.location
and
check
to
see
if
it's
empty.
If
it's
an
empty
string,
we
could
add
an
api
is
loaded
for
memory
to
system.assembly,
and
then
we
could
say
the
way
you
check
this.
E
Is
you
do
that
and
then,
if
you
call
assembly.location
without
checking
that
first,
that's
a
warning
right?
I
think
the
biggest
problem
there
is,
first
of
all,
that's
not
what
anybody
has
done
for
the
past.
I
don't
know
five
six
years
or
something
they
all
do.
Assembly.Location
is
empty,
which
is
the
thing
that,
like
that's
the
thing
we
would
warn
them
about
if
we
actually
made
this
public
like
so.
E
The
first
thing
is
everybody
doing
it
right
suddenly
gets
a
warning
and
then,
if
we,
if
we
end
up
narrowing
it
down
to
just
the
single
file,
the
is
single
file
property
is
set
to
true.
E
Then
it's
not
really
about
that
capability
anymore
right!
It's
it's
about
the
specific
property
of
single
fileness,
which
is
a
second
capability
that
we
could
also
introduce
a
second
check
for,
but
it's
not
the
same
check
asking
if
the
entire
bundle
like
if
your
entire
application
was
bundled
as
a
single
file,
is
a
different
check
than
asking
if
an
assembly
was
loaded
from
memory.
A
E
Your
question
down
to
the
thing
that
you
actually
care
about
rather
than
asking
the
broad
question
and
we
could
add,
like
a
single
file
and
supported
and
a
is
single
file
api,
but
it's
a
lot
more
niche
and
I'm
not
sure
it's
that
useful
because,
what's
the
to
some
extent,
I'm
not
even
sure,
that's
useful
for
developers,
because
if
an
assembly
is
loaded
from
memory,
you
could
probably
do
something
else.
E
If
an
assembly
is
loaded
from
single
file,
I'm
not
exactly
sure
what
the
correct
behavior
in
that
situation
would
be.
I
don't
know
I
just
don't
have
a
user
scenario
that
this
fits
well
with.
Maybe
maybe
wpf's
file,
mapping
thing
where
they
store.
They
store
files
next
to
the
application,
and
then
they
have
a
query
syntax
for
kind
of
accessing
them,
presumably
in
a
single
file
scenario
to
avoid
kind
of
littering
files.
E
Next,
to
the
unnecessarily
littering
files,
you
would
use
embedded
resources,
so
they
could
theoretically,
like
swap
off
between
embedding
new
resources
and
using
this
net
next
to
the
assembly
or
next
to
the
application
thing.
But
that's
I
don't
know
why
you
would
do
that
right.
I
would.
I
personally
would
just
switch
to
the
the
embedded
resource
thing
only
and
then
give
a
warning
for
using
the
the
query
syntax
stuff
unconditionally.
Just
like
don't
use
it.
E
So
it
there
are
a
few
apis
listed
here,
so
assembly
location,
module,
fully
qualified
name,
module,
name
assembly.getfile
or
get
files
codebase
they
don't.
Actually
they
throw,
which
is
you
know
I
like
they're,
also
obsolete.
So
I,
the
warnings
are
in
some
sense
like
unimportant
right.
It's
obsolete,
you'll,
get
an
obsolete
warning
and
those
are
the
ones
in
the
framework
that
we
know
of
in
terms
of
practical
import.
E
E
F
Single
file's,
making
this
more
apparent,
but
it
these
are
existing
complexities
of
the
existing
apis.
It's
not
new
with
the
single
file
scenario.
E
E
Yeah,
so
it's
the
behavior
for
loading
for
memory.
Basically,
we
match
the
behavior
for
loading
for
memory,
it's
always
in
brackets
unknown
when
you
load
it
from
memory.
A
E
Yeah
or
it
throws
because
of
deployment
issues,
but
that
that
one's
you
know
you
arguable
bug,
I
don't
know
whatever
also
fully
qualified
name,
I
believe,
actually
contains
the
path
yeah.
It
contains
the
path
so
that
that
one
returns
unknown
as
well.
Okay,.
I
I
A
Yeah,
I
guess
the
question
eric
is
raising
is
more
along
the
lines
of
like.
If
something
has
changed,
do
you
expect
people
to
have
two
code
paths,
one
for
a
single
file
and
one
for
not
single
file?
Because
if,
for
example,
if
you're
a
library,
you
probably
need
that,
because
you
don't
know
what
the
deployment
model
ends
up
being
for
the
app
right,
so.
E
I
I
I
E
I
A
E
Yet
yeah,
I
don't
have
anything
on
my
radar
that
we
would
be
interested
in
adding
so
for
one
it's
because
we're
no
longer
doing
extraction,
except
for
native
binaries
that
all
that
gets
a
little
bit
simpler
right,
appcontext-based
directory
returns,
the
location
of
the
exe
there's,
there's
a
lot
less
complexity.
There.
E
Yeah,
I'm
not
exactly
sure
what
the
proposal
would
be
in
those
situations.
I
I
do
know
one
api
which
we
would
consider
adding,
which
is
ask
for
the
location
of
the
extraction
directory
of
the
native
assemblies.
E
F
Do
we
have
any
apis
that
talk
about
a
deployment
model
like
I
feel
like
somewhere?
There's
a
you
know,
something
that
you
can
ask
if
you're
an
apex
container
thing
and
maybe
somewhere
there's
the
am
I
hosted
by
iis
instead
of
by
the
the
normal
xe
shim
and
other
things
like?
Is
this
a
thing
that
fits
somewhere
to
ask
this
question?
Otherwise
it
does
sound
like
we
do
want
assembly
dot
is
loaded
from
memory
or
is
ephemeral
or
you
know
whatever.
F
F
F
The
when
would
that
turn
on
like
do
you
have
to
just
explicitly
opt
into
this
particular
analyzer,
because
if
you're
writing
an
application
and
you're
not
single
file,
you
don't
care
if
you're
writing
a
library
for
yourself
and
you
don't
care
about
single
file
deployment,
you
don't
care
and
if
you're
writing
a
library.
Otherwise,
then
it's
like
browser,
maybe
you
care
so
like
you
kind
of
need
to
opt
in
to
know
whether
or
not
this
thing
is
going
to
apply
to
any
scenario
you
ever
care
about.
E
A
I
mean
to
me
capability
the
original
idea
of
the
capability.
One
was
basically
to
say:
you
know
the
the
the
platform
support,
one
that
we
currently
have
is
kind
of
unconditional
right.
You
just
say
you
know
this
api
exists,
so
it
doesn't
exist
and
then
we
just
set
the
platform.
Checks
are
the
corresponding
capability
apis
and
then
the
question
was.
Can
I
generalize
this
so,
for
example,
that
we
can
say
I
don't
know
when
you,
when
you
have
a
registry,
you
instead
of
saying
is
windows.
You
would
say:
registry
dot
is
supported
right,
but.
B
A
A
A
E
It
also
seems
problematic
to
enable
that,
like
if
we
brought
if
we
make
it
more
generalizable
than
what
we
have
here,
which
is
like
single
file
and
supported,
and
we
make
it
is
assembly
and
memory
right.
Then
the
the
corresponding
broadening
would
be
to
stop
turning
this
analyzer
on
only
for
publish
single
file
and
turn
it
on
all
the
time.
But
that
seems
like
really
noisy.
A
I
think
this
was
the
other
question
that
the
jeremy
kind
of
implicitly
asked,
which
is:
how
do
I
opt
in
right
because
I
think
similar
to
libraries
like
if
you
build
the
blazer
app,
then
we
only
opt
you
in
into
you
know
one
for
blazer
apis
that
are
unsupported,
but
we
don't
do
that
for
libraries
by
default,
but
you
can
do
something
to
your
project
to
say.
I
still
want
to
know
whether
I
don't
work
in
blazer,
because
I
intend
this
to
work
in
blazer.
A
So
in
your
case
the
question
would
be
is
what's
the
opt-in
mechanism
for
these
kind
of
things,
and
that
might
just
be.
You
know
I
don't
know
a
warning
entry
in
the
project
file.
That
says
you
know
I
want
to
know
about.
I
don't
know
single
file
issues
right
and
I
think
that's
that's
kind
of
the
user
experience
that
we
think
we
should.
A
We
should
think
about,
so
that
we
don't
have
for
those
analyzers,
this
opt-in
mechanism
for
this
analyzes,
that
update
mechanism-
it
should
be-
you
know-
hopefully
somewhat
uniform
for
that,
but
I
think
the
general
like,
I
think
I
think,
capability
based
analysis.
You
know
it's
more
concept,
I
think
the
way
we
want
to
model
these
things.
So,
for
example,
if
we
say
you
know
there
is
an
api
that
is
unsupported
in
a
certain
scenario.
A
How
do
I
check
for
that
scenario,
and
hopefully
there
should
be
a
pretty
straightforward
pattern
that
I
can
use
and
the
pattern
might
be
as
simple
as
saying
you
know,
if
assembly.location
you
know,
string
is
now
empty
or
something
right,
and
that
might
be
okay
right.
Obviously,
there's
a
dedicated
api
for
that.
A
I
think
in
your
case,
when
you,
when
you
have
like
12
properties,
it
might
be
not
insane
to
say
the
person
just
checks
the
property
itself
right,
but
if
some
of
them
throw
in
some
of
them
down
throw,
then
that
also
goes
out
the
window
a
little
bit
right,
in
which
case
the
pattern
would
get
more
complicated,
in
which
case
probably
an
api
would
make
more
sense.
A
E
F
Yeah
am
I
feeling
sort
of
like
you
know,
we're
talking
a
half
dozen
to
a
dozen
things.
If
we're
adding
a
new
attribute
to
drive
an
analyzer,
then
it
only
works
in
net
six
plus
this
seems
small
enough
that
special
casing
and
analyzer
just
seems
better
plus
it's
not.
None
of
these
apis
are
unsupported
in
single
file,
which
is
what
the
attribute
says.
F
It's
they
just
probably
don't
do
what
you
kind
of
want
them
to
do,
because,
as
you
mentioned,
you
could
assembly.load
to
load
a
sidecar
assembly
and
it
has
a
location
just
because
the
the
main
components
of
your
application
don't
doesn't
mean
that
nothing
does
versus
the
stuff
that
we've
painted
in
browser
with
browser.
Unsupported
is
like
no
really
like.
This
is
just
gonna,
throw
it's
it's
dead.
There
is
no
workaround,
there's
no
subtlety.
It's
this
api
does
not
work
check
it
before
you
call
it.
E
So
the
question
would
be:
what
do
we
do
about
the
user?
Basically,
what?
What
do
we
do
about
apis
that
a
library
offers
that
depend
on,
let's
say
just
assembly
being
on
disk?
A
Yeah
the
same
question
because,
like
if
you
think
just
about
v1,
for
example,
right
mapping,
one
has
an
directory
catalog
right
that,
basically
you
instantiate
it
with
a
pass,
and
then
it
finds
all
the
assemblies
and
loads
that
most
of
the
time
people
will
instantiate
with
the
application
directory,
in
which
case
the
catalog
would
be
empty
right.
So
it
will
work,
but
it
won't
do
what
you
want
it
to
do
right,
and
so
I
think,
that's
kind
of
the.
A
The
question
I
think
is
like:
how
do
you
bubble
this
up
right?
How
do
we
can
like
do
and
attributes
are
convenient
to
do
that
right,
because
then
you
find
all
the
locations
in
your
code
that
uses
the
apis
that
are
marked,
and
then
you
can
decide
which
of
your
own
stuff.
Your
markup
is
attribute
right
and
then
they,
presumably
the
analyzer,
is
smart
enough
to
suppress
any
warnings
that
occur
in
apis.
That
are
already
marked
with
this
attribute
right.
E
Yeah,
the
the
the
model
is
that
the
our
our
idea
is
that
for
single
file
and
supported
or
whatever
we
would
like
to
call
it.
If
you
have
that
on
your
method,
then
any
warning
that
would
be
produced
by
the
analyzer
about
single
file
and
supported
would
be
silenced.
By
having
the
attribute
effectively
it's
it's
viral
it.
It
just
moves
up
the
chain.
I
A
E
E
Yeah
but
remember
that
if
they
set
so
right
now,
if
you
basically,
if
you
do
this
today,
then
you'll
get
a
warning
on
your
code.
If
you
call
assembly.location
and
then
publishes
a
single
file
right,
the
difference
is
that
if
we
make
this
viral,
then
other
libraries
could
slap
this
attribute
on
their
methods
and
then
in
this
case
the
user
who's.
Actually,
writing
their
app
will
get
a
warning
from
the
analyzer
about
using
an
api
from
a
third-party
library.
That's
not
supported,
or
it
doesn't
work
properly.
E
F
But
in
a
two
library
dependency
model,
I'm
just
making
sure
we
understand
what
we're
talking
about
here.
You
know,
shane
is
broken.
F
Adds
one
of
these
things,
azure
sdk,
doesn't
add
one
of
these
because
they
weren't
compiling
with
the
extra
I
want
to
know
when
I've
used
this
thing
warnings
you're
using
the
azure
sdk.
You
completely,
don't
notice
that
you
now
have
so
you
have
an
in
implicit
dependency
and
you
don't
get
the
warning
yeah!
That's
right!.
E
I
Talk
about
other
problems,
what
would
I
do?
What
would
I
do
if
I'm
an
app
developer,
who
uses
library
a
that's,
got
one
of
these
apis
that
are
marked
with
this,
and
I
get
a
warning
now?
What
like
do
I
I
switch.
I
can't
call
that
api.
Do
you
know
what
I
mean
like
there's
there's
no
way
for
me
to
switch
it's
better
in
the
library
case
right
in
the
azure
sdk
case
they
get
the
warning:
how
do
they?
A
Yeah,
I
I
guess
my
my
question
for
andy
is
is
like,
like
ignore
third
party
just
say
it's
all
the
one
solution.
I
have
an
app
project
that
references,
a
library
project
and
then
my
library
project
does
the
thing
and
then
my
app
project
just
calls
for
library
project.
That
is
also
dropped
on
the
floor
right
now,
even
though
in
this
case
we
kind
of
know
what
the
closure
is
right,.
A
My
understanding
is
that
not
by
default
right,
because
we
don't
opt
libraries
in
by
default
to
say,
give
me
single
file
warnings,
because
we
assume
they
are
very
noisy.
So
by
default,
the
library
wouldn't
get
a
warning
and
then
the
app
wouldn't
get
one
either
because
well
the
app
didn't
know
about
it.
J
E
E
Yeah,
that's
actually,
I
don't
think
that's
true,
but
I
do
think
that
this
one
is
scoped
down.
I
think
you
will
so,
for
example,
if
you
set,
I
think
if
you
set
dash
p
publish
single
file
equals
true.
E
A
F
Yeah
so
my
great
yeah,
my
my
big
concern
with
this
is
really
the
word
unsupported
because,
as
you
know,
it
single
file
makes
this
problem
more
apparent,
but
in
single
file
it's
not
always
broken
and
it's
sometimes
broken
outside
of
single
file.
So
it's
it's
not
really
related
to
single
file
and
it's
not
really
unsupported,
and
so
this
is
really
like.
E
That's
fair,
but
I
I
do
want
to
point
out
that
sometimes
we
get
overly
abstract
and
then
end
up
confusing
people
in
the
process.
This
is
a
common
problem
with
the
c
sharp
compiler,
where
we
give
some
terminology,
that's
technically
correct.
It's
like
yeah.
This
thing
is:
that's
a
invalid
identifier
and
people
like
what
the
hell
does
that
mean.
I
F
A
Yeah,
I
think
that
I
think
the
the
challenge
here
is
that
the
other
case
where
this
can
happen,
meaning
you
know
you
loaded
an
assembly
from
binary-
is
so
excessively
rare
in
practice
that
it
doesn't
really
matter
right.
The
reason
why
people
are
broken
by
this
most
often
will
be,
because
somebody
enabled
single
file
right,
and
so
that's
why
it's
probably
well.
B
A
Single
file,
but
then
the
error
message
is
something
like
well.
This
could
be
dynamically
generated
assembly,
so
please
make
sure
to
check
whether
location
is
not
null
or
something.
People
are
like.
What
the
are
you
talking
about
right
that
doesn't
make
any
sense
for
what
I'm
doing,
and
so
I
think
that
that's
why
I
think
I
I
could
live
with
single
file
as
being
the
thing
I
mean,
unsupported
might
be
a
bit
of
a
strong
term
here,
because
to
me
unsupported
means
the
api
will
throw
which
it
wouldn't.
A
It
would
just
give
you
not
useful
answers,
potentially
right
and
so
that
that
might
be
the
nuance
if
you
want
to
figure
out,
but
I
don't
know
what
to
say,
like
you
know,
single
file,
please
think
about
this
attribute
is
also
single.
A
But
yeah
I
mean
also,
I
guess
it
also
depends
on
what
the
er,
what
the
message
would
be
right
if
the,
if
the
message
is
a
more
along
the
lines
of
like
this
api
may
not
be
supported
or
may
produce
incorrect
results
in
single
file,
I
think
it's
probably
fine
right.
E
Yeah,
so
the
message
would
probably
be
something
generic
like
that,
and
then
the
attribute
takes
a
string
parameter
for
the
message
and
then
that's
an
additional
message
that
the
user
can
that
the
person
who's
applying
the
attribute
can
put
in.
A
B
E
E
Yeah,
I'm
just
saying
like
I
I
thought
about
this
because
I
was
like
what
could
we
possibly
like?
Are
we
backing
ourselves
into
a
corner
here?
If
we
do
this,
and
the
answer
is
no
and
also
for
third-party
applications,
I
don't
have
a
better
alternative
right,
there's,
no
way
that
they
can
ship
us
localized
resources
for
their
no.
A
That's
why
I
think
like
to
me
the
the
pattern
would
be.
You
would
not
have
a
message
and
it
would
just
have
a
gen,
an
optional
url
right,
and
so,
if
you
want
to
provide
details,
you
provide
a
url
and
then
the
whoever
authors,
library,
controls
what's
behind
that
url
and
that
can
be
localized
or
cannot
be
localized
right.
That's,
depending
on
what
they're
doing.
A
B
A
A
E
I
think
that's,
I
think
this
is
viable
for
a
single
file,
because
it's
rare
enough
and
specific
enough
that
we
could
do
that.
But
for
like
the
linker,
it
would
be
a
nightmare
to
try
and
you
get
the
same
generic
message
and
then
you
would
have
to
go
to
a
url
in
order
to
figure
out
what
the
problem
is.
The
linker
is
complaining
about.
That
would
be
awful.
A
A
But
yeah
I
mean
obsolete
is
kind
of
similar
and
the
way
we
do
it
in
obsoletion
we
just
said:
well,
you
have
a
diagnostic
id
right
and
that's
your
key
realistically,
but
yeah
I
mean
I
think
in
general,
like
I
don't
know
what
you
want
to
get
out
of
this,
but
like
it's
turned
more
into
a
feature
discussion,
I
think
to
me
the
the
name
of
the
attribute
you
know,
modular,
the
weirdness
that
jamie
would
talked
about
seems
fine.
E
Yeah,
so
I
guess
my
my
conclusion
here
was:
do
we
want
to
go
back
to
the
drawing
board
and
use
a
completely
different
framework,
namely,
like
the
capability
analysis
stuff?
I
didn't
see
a
compelling
reason
to
do
that
right
that
if,
if
that
were
the
conclusion,
then
I
would
say
we
should
close
this
and
come
back
with
something
completely
different
right.
I
don't
hear
that.
That's
the
strategy
we
want.
I
could
also
see
us
splitting
it
into
two
and
talking
about
you
know
just
in
memory
stuff
and
just
single
file
stuff.
E
F
Does
it
take,
and
it
probably
once
its
targets,
expanded
to
everything
you
can
have
an
event
that
doesn't
work
in
single
file
yeah,
I
think
that's
fair
and
then
property
means
that
people
don't
have
to
be
confused
of.
I
want
to
put
it
on
the
property.
That's
not
applicable,
but
it
is
yeah
totally
could
be.
You
need
to
move
it
to
the
get.
E
F
A
I
mean
the
one
thing
I
would
say
is
like
I,
I
think
earlier
we
discussed
about
having
capability
api,
for
you
know
determining
whether
you
run
in
single
file
mode
or
not,
and
I
think
the
I
think
andy
said
like
it's
too
broad
of
a
net,
and
while
I
agree
with
that
in
practice,
we
often
end
up
needing
something
like
that,
because
this
additional
subtlety
that
you
can't
express
purely
with
things
like
you
know,
this
assembly
has
a
location
or
not.
A
So
we
may
want
to
consider
doing
that
regardless,
so
that
when,
when
there
is
weird
bugs
like
the
one
that
eric
mentioned,
where
we
you
know,
another
api
doesn't
work,
always
just
the
way
we
want.
People
have
at
least
a
way
to
detect
it
and
do
something
semi-useful
in
those
cases,
because
I
mean,
I
think
that's.
E
A
I
think
it's
fair
to
say
you
generally
don't
expect
people
to
clearly
that
and
then
have
an
if
and
then
else.
In
all
cases
right,
you
would
generally
say
no
you're
holding
it
wrong.
Just
write
the
code
differently
and
it
will
work
for
both
cases.
Right,
like,
for
example,
switch
to
embedded
resources
rather
than
depending
on
loose
files
on
disk.
E
A
Yeah,
I
guess
that
goes
back
to
like
it
doesn't
single,
doesn't
sing
a
file.
Have
two
modes
like
you
know,
framework
dependent
and
framework.
Was
it
framework
dependent
and
single
file.
E
So
it's
it's
got
two
other.
It's
got
two.
It
can
either
load
everything
from
memory
or
it
can
extract
everything
to
disk
the
tricky
bit.
Is
that
if
you
extract
everything
to
disk,
then
it
actually
kind
of
works
mostly
that
all
this
stuff
kind
of
just
works,
and
so
when
people
say
you
know
my
app
isn't
compatible
with
single
file.
Usually
what
they're
talking
about
is
my
app
isn't
compatible
with
loading
everything
from
memory?
I.
E
Yeah,
you
can
do
framework
dependent.
You
just
end
up
loading,
the
stuff
from
you.
You
do
end
up
loading
corelib
from
from
the
disk.
A
E
Disk,
no,
we
so
it's
a
question
of
whether
or
not
the
system,
libraries
or
the
user
libraries
are
embedded.
So
there's
there's
a.
There
are
two
axes
here:
there's
a
question
of
whether
or
not
you're
framework
dependent
right.
If.
I
E
Framework
dependent,
then
you
include
all
the
system
assemblies
right.
If
you're,
not,
then
you
don't
and
then
there's
extraction
or
load
for
men
and
if
you
load
from
mem,
then
everything
including
the
framework,
is
loaded
for
memory.
If
you
are
framework
dependent,
sorry,
if
you're,
seeing
if
you're
self-contained
everything
is
loaded
if
you're
framework
dependent,
then
just
your
assemblies
are
loaded.
A
E
A
Yeah,
I
guess
that
goes
back
to
like
what
does
the
api
give
you
right
so
that
that's?
Why
yeah?
You
probably
want
to
think
about
more
what
what
these
you
know
these
apis
would
be
and
like
what
you
would
do
with
those,
because
that's
realistically
probably
the
bigger
question
right
like
what
does
the
user.
E
That's
why
I've
resisted
editing,
adding
this
api
so
far
where
it's
like,
I'm
not
exactly
sure
what
it,
what
scenario
or
how
to
generalize
all
of
the
cases.
One
case
that
I
know
that
people
are
interested
in
is
are
native
assemblies
like
give
me
the
native
assembly
extraction
directory.
If
one
exists-
and
that's
I
mean
the
is
single
file-
check-
isn't
very
useful
for
that
at
all,
but
doesn't
that
kind.
I
F
Yeah,
I
think
you
know,
in
terms
of
capability
api,
the
one
that
seems
the
most
useful
because
looking
at
you
know,
assembly
location
assembly
get
file
and
assembly
get
files
is
an
instance.
Member
on
assembly
of
is
loaded
from
memory.
I
A
Yeah,
I
think,
even
if
you
look
at
our
own
stuff,
I'm
sure
that
we
will
find
cases
that
are
indirectly
depending
on
this,
like
I
mean,
as
I
said
earlier,
like
meth
is
just
one
example,
but
I'm
pretty
sure
there's
corresponding
asp.net
apis
that
have
very
similar.
I
guess
a
split
doesn't
support
signal
file,
but
you
know,
as
you
go
up
the
stack,
I'm
sure
you
will
find
cases
like
that
and
then
the
question
is
what
are
we
doing,
because
we
don't
want
to
specialize
them
all
either
right.
E
E
E
And
yeah
like
it,
it
would
a
finer
grained
attribute,
like
the
the
big
problem
here
being.
What
if
I
want
to
check
if
the
assembly
location
returns
empty,
I
now
get
a
warning
right.
The
only
recourse
is
to
just
suppress
that
warning,
because
I'm
checking
to
see
whether
or
not
I
am
actually
loaded
for
memory
like
that
is
the
recommended
way.
We
could
add
another
api.
That
does
that.
That
doesn't
produce
a
warning
and
I
think
that's
very
reasonable.
E
F
Yeah
I
mean
the
compiler
obviously
has
some
form
of
that,
because
it
knows
you
know
where
can
be
assigned
to
things
or
or
not,
but.
E
Yeah-
and
it
is
hard
I,
as
the
author,
I
will
say
it's
very
hard.
F
I
totally
believe
it
but
yeah,
so
I
I
think
it
would
be.
You
know
reasonable
to
add
a
boolean
property
on
assembly
for
the
capability
check
so
that
if
one
day
we
have
instance
based
flow
analysis
that
you
get
the
easy
boolean.
That
way,
we
don't
have
to
ask
it
for
okay,
if
they
send
it
to
string
that
is
null
or
empty
or
string
that
is
null
or
white
space,
or
they
did
equal
equal,
the
empty
string
or
they
did
equal
equal
string.empty
or
they
did.
F
E
F
What
would
be
a
single
file
and
supported
that
is
not
requires
location
on
disk
like
if
we,
if
we
started
with
the
specific
problem
and
then
waited
until
we
had
a
generalization
to
use
the
bigger
name?
What
would
it.
E
A
Yeah,
I
think,
having
a
a
global,
I
don't
know,
but
we
would
put
that.
That's
the
other
question
like
if
we
have
something
like
you
know,
a
single
file
we
would
have
to,
and
we
would
have
to
decide
where
to
put
this
right,
because
one
of
the
problems
is
like
is
that
the
only
mode
we
have
or
will
there
be
other
modes
in
the
future?
Where
you
know
half
the
stuff
is
linked,
the
other
half
is
not
or
something
right.
These
are
the.
A
This
is
the
problem
of
hosting
models,
because
there
are
so
many
right
and
and
then
the
question
is:
where
should
this
belong?
But
I
think
practically
speaking,
we
probably
should
have
an
api
somewhere,
because
it
seems
that
there
will
be
workarounds.
People
will
have
to
make
to
make
single
file
modes.
Work
would
be
my
guess.
E
Okay,
so
let's
let's
say
we
don't
have
a
lot
of
information
here.
What's
the
change
that
we
think
improves
the
world,
but
is
also
flexible
enough
that
we
could
change
it
later.
It
feels
to
me
like
some
sort
of
single
file
and
support
it.
Basically,
a
global
check
global
like
if
you
have
published
single
files.
True,
then
this
thing
warns.
E
We
could
always
introduce
an
is
single
file
api
later
for
that
specific
check,
and
if
we
want
to
drive
down
on
things
like
assembly.location,
we
could
probably
replace
the
attribute
specification
in
later
versions
of
the
framework
from
single
file
and
supported
to
requires
location
on
disk,
but
it
gives
us
some
work
now
that
that
is
useful.
Does
that
sound.
A
Sort
of,
I
think,
I
think
it's
half
of
the
work.
I
think
the
other
half
of
the
work
is
for
every
api
that
you
would
like
to
get
a
warning
for.
You
should
be
able
to
express
in
one
paragraph
of
like
what
you
want
the
user
to
do.
If
the
answer
is
write
your
code
differently
and
will
work
for
both
cases.
E
L
E
But
the
single
file
and
supported
attribute
seems
like
a
whole.
It's
a
pareto
benefit.
It
just
makes
things
better
and
it
doesn't
necessarily
lock
us
into
keeping
this
attribute
on
things
like
assembly.location.
If
we
want
to
replace
it
with
a
more
fine-grained
thing
in
the
future,.
F
F
Yeah
so
there's
add
the
attribute
so
that
the
analyzer
can
be
can
start
getting
closure
or
the
the
method,
closures,
reporting
warnings.
I
think
that
there's
value
in
having
a
property
on
assembly
that
replaces
checking
location
against
the
empty
string
you
it
returns
a
boolean
because
of
boolean's.
What
you're,
after
of,
is
this
a
memory
assembly?
It's
independent
of
this
yeah
and
then
third
is
the
is
my
hosting
model
single
file
or
what
is
my
hosting
model
to
be
able
to
answer
this
question?
F
I
I
don't
know
where
that
one
fits,
so
I
don't
have
good
names
for
it,
but
it
feels
like
a
third
thing
that
can
be
deferred.
I
mean
the
second
one
can
also
be
deferred.
I
just
think
it's
good
to.
A
E
E
Sure
is
like
fine,
adding
assembly
dot.
You
know
is
loaded
for
memory
that
that's
a
convenience
api.
We
probably
wouldn't
even
respect
it
with
respect
to
this
attribute.
So
it's
a
separate
discussion
right
like
we're
not
going
to
use
that
information
in
any
way.
When
warning
about
this
attribute
so.
A
A
E
F
Yep,
that's
reasonable
yeah,
so
the
attribute
usage
needs
to
be
expanded
to
whatever
seems
more
reasonable
right
now.
It's
too
constrained,
I
think
we
said
we
wanted
to
get
rid
of
the
customizable
message
because
of
globalization
problems.
Unless
it's
localization
problems,
I
can't
remember
which
ones
which
and
and
then
I
would
be
happier
if
we
could
replace
the
word
unsupported
with
something
else,
but
andy
seems
to
not,
like
my
impacted,
so.
E
A
Yeah,
I
mean
I'm
fine
with
unsupported
or
impacted.
I
think
to
me
the
question
is
more
like
what
do
you
put
in
the
actual
message
that
you
put
spit
out?
I
think
this
one
has
to
convey
the
nuance,
but
I
think
that
one
is
doable
in
terms
of
expansion.
Jeremy.
What
do
you
think
you
think
constructor
and
method
is
too
restrictive?
Is
that
what
you
meant.
F
Yeah,
like
the
api
catalog
site,
seems
to
have
gotten
a
lot
harder
to
use
since
you
updated
it,
but
supported
os,
has
assembly
module,
class,
struct,
enum,
constructor
method,
property
field
and
event.
I
don't
think
struct
seems
weird,
also
enum.
I
don't
know
why
we
said
enum
wouldn't
work
on
a
os,
but
so
event,
property
method,
constructor
and
I
guess
class
instruct
if
you
want
to
just
paint
the
whole
type
and
then
maybe
assembly
in
module.
D
A
E
A
Thank
you,
andy
sounds
good
all
right,
so
then,
let's
go
with
all
for
now.
Something
else
are
we
happy
with
the
namespace?
I
think
it
seems
like
the
right
namespace
based
on
where
the
other
stuff
lives.
F
Unless
we
want
it
to
be,
I
guess
we
probably
want
it
to
be
optional.
So
then
there
need
to
be
overloads,
or
I
guess
that
just
means
it
gets
that
property.
A
F
A
Reasonable
then,
I
suggest
you
just
take
the
shape
that
we
have
on
the
other
side
and
have
basically
diagnostic
id
get
set
and
url
format
gets
it
and
then
the
diagnostic
id
can
be
referenced
by
the
url
format,
similar
to
how
we
do
it.
For
the
platform
compatibility
one
sounds
good.
We
shouldn't
take
a
message
because
they
are
hard
to
change.
A
We
should
take
a
diagnostic
id
all
right.
So
then,
let
me
paste
this
in
and
mark
this
as
api
approved.
J
C
Yes,
can
you
refresh
please,
okay,
you
got
it
all
right,
so
web
sockets
have
has
an
extension
that
allows
message
compression.
C
C
Then
we
have
the
sort
of
maximum
deflate
window
bits.
It's
basically,
the
the
number
of
bytes
described
in
bits
of
how
large
the
compression
window
will
be
defaults
to
32k.
C
Yeah,
so
next
we
have
this
idea
of
context
takeover.
Essentially,
the
window
is
dynamic
for
a
single
message,
but
if
you
have
takeover
set,
it
means
that
the
window
will
be
persisted
across
all
of
your
messages,
potentially
offering
better
compression,
but
forcing
you
to
store
this
potentially
very
large
window
for
every
connection.
C
C
C
F
Was
because
the
moment
that
they
add
another
rfc
to
say
well
in
addition
to
deflate
now,
it
supports
gzip,
it's
like,
but.
H
Even
even
for
the
existing
thing
there's
an
issue
we
have
with
asp.net,
where
asp.net
needs
to
be
able
to
differentiate
behavior
with
basically
customize
the
abort
behavior
for
a
websocket
and
so
there's
another
issue
where
we're
discussing
the
ability
to
provide
a
delegate,
that's
invoked
upon
websocket.abort.
H
C
All
of
these
are
hints
this,
because
it's
an
extension,
the
server
can
reject
compression
completely.
It
can
assign
you
a
smaller
amount
of
bits
if
it
wants
to
save
memory,
if
it
has
a
lot
of
clients,
maybe
so
all
of
these
are
hints.
H
C
F
C
We
could
potentially
leave
the
usd
compression
property
off
for
the
server
and
just
you
know
have
it
ignore
the
extension
or
something
but.
C
Yeah,
so
it's.
C
G
C
Yeah,
if
we
wanted
to
add
additional
apis,
we
could.
C
You
can
send
this
extension
multiple
times
saying
this
is
my
preferred
option,
but
if
not
this
try
this,
it
didn't
really
look
like
it
was
in
bit
wide
use,
so
I
left
it
off,
but
we
can
add
that
in
the
future.
G
C
So
there
is
a
per
message
option
on
the
rfc,
but
we're
leaving
that
out.
It
would
have
just
been
extra
apis
and
we
haven't
really
seen
data
to
see
that
people
would
use
it
just
yet.
But
we
can
add
that
on
later
cleanly,
if
we
need
to.
G
A
A
F
One
possibility
would
be
you
do
create
the
new
type
for
the
three
things
you
have,
plus
this
other
thing
or
either.
We
overload
and
add,
take
the
client
it's
now
slightly
misnamed
client
websocket
options
as
a
fourth
parameter
and
now
they're
inherently
kept
aligned
or
we
make
a
websocket
creation
options
which
has
a
client,
websocket
options,
poorly
named
property,
just
wondering.
C
C
So
the
client
websocket
options
does
have
additional
properties
that
are
kind
of
specific
to
connecting
the
uri.
Okay
and
the
websocket
creation
options
has
the
is
server
and
sub
protocol,
which
maybe
we
could
pass
as
parameters
if
we
really
wanted
to.
A
A
F
Yeah,
like
I'm
slightly
wondering,
do
we
want
like
right
now
you
have
the
three
things
that
already
were
thought
to
make
sense,
plus
a
bunch
of
things
that
are
related
to
this
one
extension
and
then,
if
I'll
just
say
gzip,
because
it's
another
compression
scheme
gets
added
and
it
uses
very
different
notions
of
control.
Like
would
we
want
some
sort
of
grouping
like
a
basically
a
deflate
compression
properties
or
deflate
compression
options?
Is
the
property,
and
then
it
has
these
four
things
in
it.
F
C
I
mean
that
would
make
it
future
proof
new
extension
might
come
out.
My
current
view
is
websockets
is
actually
going
to
be
obsoleted
in
the
near
future.
C
Obviously
I
don't
honestly
know
how
many
more
extensions
are
going
to
be
defined
for
it,
but
if
we
wanted
to
be
safe,
you
know.
The
comment
I
have
here
says
take
these
and
make
it
a
deflate
compression
options
class,
and
I
guess
we
could
use
a
base
class
or
something
to
make
it
just
one
property.
C
A
A
Well,
I
guess
the
idea
would
be.
We
take
use,
deflate
compression
all
the
way
down
to
server
deflate
context
takeover
and
we
would
basically
put
them
into
a
new
type
called
websocket
deflate
options,
and
then
we
would
add
this
as
a
property
to
both
client,
websocket
options
and
websocket
creation
options.
And
so
this
way,
if
we
add
another
setting
for
deflate
it's
in
both
places
and
if
we
ever
add
something
else
that
is
not
deflate
like
gzip,
then
we
would
add
a
new
type
for
that.
A
A
F
If
it
got
added,
there
would
be
a.
How
are
you
supposed
to
resolve
if
the
client
supports
both
right
this?
Presumably
it's?
They
send
both
things
in
negotiation
and
the
server
responds
with
which
one
I
wanted
to
do
right
yeah.
So
I
especially
without
you
know,
because
the
next
thing
could
be
instead
of
gzip
compression.
It
could
be.
F
I
guess
we
could
have
reused
that,
but
oh
well
just
seems
a
bit
more
scoped
in
purpose,
and
then
we
don't
have
to
worry
about
like.
Oh,
we
need
to
put
deflate
in
the
name
of
all
of
these
properties
to
tell
you
that
they're
all
related
to
deflate
compression.
So
it
would
be,
you
know,
deflate
compression
connection
options
or
something,
and
then
it
would
have
client
max
window
client
context
takeover
like
you
get
to
simplify
all
the
property
names,
because
the
type
is
providing
their
context.
C
Yeah,
I'm
fine
with
that.
The
reason
I
kind
of
flatten
them
out
into
this
one
class
like
this
is
we
kind
of
took
the
same
approach
in
sockets
handler
of
not
creating
a
new
class
to
cluster
options
that
need
to
be
set
together.
F
If
you
want,
you
know,
it
seems
like
you're,
probably
going
to
have
a
set
of
compression
options
that
you
want
to
use,
maybe
across
multiple
sockets,
because
it's
you
know,
there's
a
thing
about
your
application,
but
that
the
once
you're
needing
to
configure
the
other
things
it's.
How
often
are
you
going
to
build
the
thing
versus
you
just
built
the
these
are
my
deflate
options,
go
build
a
websocket
here
are
the
deflate
options,
and
so
that's
another
reason
that
it
could
be
make
more
sense
as
a
separate
class.
A
L
Somewhat
orthogonal
the
general
issue
here
about
these
kinds
of
option
classes
moving
forward.
I
wonder
with
c
sharp
nine
adding
records
and
better
support
for
immutable
objects.
Should
we
be
moving
more
towards
making
options
classes
like
this
immutable
and
manipulating
them
as
immutable
objects,
instead
of
making
them
mutable,
because
there's
certainly
advantages
from
having
it
be
having
these
kinds
of
things
be
immutable.
A
Yeah,
that's
a
good
question.
I
think
the
I
don't
know
enough
about
records
yet
to
have
an
opinion
on
this
I
mean
the
the
normally
the
argument
against
immutable
data
types.
Is
that
they're
much
more
harder
to
use?
Basically
because
you
have
to
have
either
constructors
that
take
long
number
of
arguments,
in
which
case
you
have
this.
A
You
know
colon
syntax
that
people
have
to
you
know
think
about,
and
if
you
want
to
change
one
property
you
either
had,
which
makes
things
slightly
more
ugly
to
use
assignments
are
easier
for
most
people,
but
I
think
the
record
syntax
makes
that
easier.
But
I
haven't
really
looked
into
this
in
great
detail.
Yet.
H
So
I
do,
I
do
have
a
innate
concern
with
using
records
pretty
much
anywhere
and
done
at
runtime.
They
are
a
really
cool
thing
and
they're
great
for
applications
to
use,
but
for
one
the
surface
area
that
gets
generated
for
them
is
not
baked
yet.
So
you
know
we
don't
really
have
control
over
what
apis
are
showing
up
for
a
record.
H
Lots
of
stuff
shows
up
when
you
create
a
record,
and
the
second
is
related
to
that.
You
define
a
simple
record
and
the
amount
of
il
and
assembly
that
gets
generated,
for
it
is
staggering,
because
every
thing
has
withers.
There's
a
quality
overrides.
There's
constructors
there's
you
know
interface
implementations.
It's
all
this
wonderful!
You
know
tostring
that
pretty
prints
all
your
state
like
there's
a
ton
of
stuff,
that's
really
useful
for
someone
who's
writing
an
application,
but
for
folks
like
us
that
care
a
lot
about
control
and
size
and
being
slim
and
whatnot.
H
L
H
L
H
There
are
so,
for
example,
like
I
would
have
no
qualms
or
very
few
qualms
with
us,
using
init,
only
properties
which
solves
the
constructor
issue.
That
emo
was
referring
to
and
it
only
properties
is
sort
of
a
language
level
feature.
You
could
still
use
reflection
to
get
around
it,
but
basically
it
lets.
You
define
an
immutable
property
that
you
can
still
set
as
part
of
an
object.
Initializer
right,
so
you
could
say
new
web
socket
options
and
inside
your
braces,
you
could
set
whatever
properties
you
want
to
set.
H
L
A
G
H
Well,
the
question
I
think
would
be:
I
don't
remember
where
we
landed,
but
it's
possible.
The
c
sharp
compiler
emits
a
poison
pill
in
the
form
of
a
mod
op
or
a
mod
wreck
or
whatever.
A
That
might
be
also
the
killer,
then
right,
fair
enough
yeah,
so
it
seems
like
we
should
definitely
look
into
this.
I
mean
in
the
past
the
way
language
features
used
to
work.
Is
that
they're,
more
composable?
Where
you
can?
You
know
when
you
take,
for
example,
link?
You
can
use
extension
methods
without
using
link
and
stuff
like
that
right.
So
maybe
the
apply
method
that
they
have
is
a
general
pattern
that
we
could
use.
That
would
work
without
buying
into
all
the
records,
for
example
right.
So
I
think
they
are
certainly
like.
A
L
I
think
that
I
think
that,
while
the
c-sharp
guys
are
off
trying
to
make
immutable
stuff
better,
we
are,
it
seems
worthwhile
for
us
to
be
working
with
them,
with
the
hope
that
the
the
things
that
they
do
to
improve
immutability
will
allow
us
to
use
that
immutability
in
more
classes
and
more
areas
in
in
the
bcl.
And
if
we
can't
do
that,
then
that
feels
like
we
haven't
really
solved
the
problem
entirely.
B
A
B
L
I
I
I'm
totally
happy
to
say
look
records
is
a
app
thing
and
it
generates
a
ton
of
like
you
know
special
handling
here,
but
I
guess
I'm
kind
of
getting
to
the
the
sort
of
layering
argument
that
you
were
making,
which
is
that
the
whatever
they're
building
ought
to
be
layered
in
such
a
way
that
we
can
opt
into
the
stuff
that
helps
us
use,
immutability
more
broadly
in
bcl
classes,
without
paying
the
full
price
that
an
application
is
paying
when
they're
using
like
the
whole,
full-blown
record
capability
right.
F
A
G
So
I
have
a
question
about
the
max
window
bits.
So
I've
been
like
skimming
the
rfc
and
I
probably
missed
a
lot
of
it,
but
it
seems
like
the
client
sends
the
extension
first
like
the
extension
payload,
with
like
the
bits
that
it
wants
to
use
for
like
the
server
window
and
the
client
window,
and
then
the
server
responds
with
either
like
the
same
numbers
or
what
it
chooses.
G
If
I
just
want
to
use
whatever
like
on
the
server.
If
I
just
want
to
use
whatever
the
client
asks
for.
How
do
I
specify
that.
C
I
think
that's
kind
of
up
to
the
implementation.
I
would
be
treating
these
as
maximum
values.
So
it's
what
the
client
wants
as
a
maximum
and
it's
also
the
maximum
that
the
server
would
accept.
So
the
server
will
negotiate
the
minimum
between
the
values.
F
Yeah,
presumably
the
actual
implementation,
the
max
window
bits
aren't
going
to
be
simple,
get
set
with
an
initializer
because
they're
going
to
throw
for
negative
numbers,
but
yeah
that
way.
We
don't
have
to
do
that
check
everywhere.
That
reads
this
thing:.
F
But
yeah
the
shape
and
the
general
notion
of
we
we're
providing
defaults
that
are
good
and
yeah
to
jeff's
point
of
you
know
if
we
can,
if
we
could
be
using
things
like
you
know,
get
init,
then
that
would
allow
us
to
have
a
nice
singleton
of
deflateoptions.default,
but
I
don't
know
that
we
want
to
it.
F
That's
not
worth
doing
all
the
gymnastics
for
I'm
a
locked
type
without
having
a
good
pattern
for
things
and
with
steve's
concern
that
either
we're
cutting
off
f,
sharp
or
things
get
weird
with
non-c
sharp
languages.
I
don't
know
that
we're
ready
for
getting
it
yet.
H
I
had
a
question:
I'm
sorry
this
was
answered
earlier,
but
any
given
websocket
is
either
a
client
or
a
server
does
do
the
other
set
of
properties
have
meaning.
In
that
case,.
F
And
just
to
see,
if,
if
I
understand
that's
really
the
test
here,
the
client
says
what
it
thinks
the
server
should
do
and
when
you're
the
server
you
have
the
ability
to
restrict
what
the
the
client
will
do
so
either
side
sends
both
or
has
both
things
and
whatever
gets
negotiated,
is
the
minimum
of
either
of
those
properties.
But
the
roles
are
named,
for
which
role
and
not
for
like
me,
another
guy.
C
Yeah,
yes,
if
we
wanted
to
make
this
clearer,
maybe
it
we
could
maybe
use
local
and
remote
instead
of
client
and.
F
G
L
F
C
K
Yep,
can
you
hear
me
yep
okay,
so
this
issue
is
about
party
with
newton's
of
json
well,
but
basically,
just
to
give
a
bit
of
context
on
five,
we
added
a
reference
hundred
preserve
property
in
order
to
have
the
party
when
you
deserve,
and
also
have
an
alternative
that
can
deal
with
circularity
and
energy
graph.
When
you
see
ls
using
system,
taxation.
K
So
proserv
was
able
to
satisfy
many
people
stepping
into
circularity,
probably,
but
there
was
some
audience
still
asking
for
not
using
preserve,
but
rather
they
prefer
they
would
prefer
to
use
something
that
is
like
ignored
on
youtube.
B
K
This
is,
this
is
the
pro
this
is
the
proposal
to
satisfy
that
need
some
motivations,
for
that
is
not
just
ask
the
people
asking,
but
the
payloads
created
with
reserve.
K
First
of
all,
they
are
not
like
json
spec
friendly
and
also
they
might
be
too
cumbersome
and
might
increase
the
payload
side.
In
the
worst
case
scenario,
and
also
when
you
serialize
with
pressure,
the
json
created,
is
incompressible
for
our
serializers
for
serialization
json.net
and
system
six
json.
K
Basically,
this
is
having
one
static
property
next
to
preserve.
That's
called
ignore
cycle.
A
F
K
F
K
Well,
if
you
want
to
scroll
down
a
little
bit,
there's
some
considerations
or
risks
to
consider
with
this
that
people
that
is
obtaining
for
the
option
should
be
aware
of.
One
of
we
have
already
discussed
them
in
the
past
when
we
were
discussing
preserve.
One
of
them
is
the
silent
loss
of
data.
K
Let's
say
that
you
have
a
list,
and
one
of
the
elements
will
cause
will
cause
reference
loop
or
will
be
the
beginning
of
the
reference
loop.
It
will
be
ignored
and
then
your
list
instead
of
having
let's
say
it,
had
it
had
three
elements.
Now
it's
gonna
have
two
and
that's
one
concern
and
the
other
one
is
that
it's
still
soon
able
to
run
trip
to
data
right,
because
it's
not
it
losses
the
integrity.
A
I
mean,
I
think,
swim
to
last
time.
I
I'm
still
somewhat
at
lost
in
how
somebody
reasons
about
ignore
cycle
like
because
I
mean
that
sounds
great
in
principle
but
like
if
you
have,
for
example,
a
tree
where
nodes
know
their
parent,
like
I
don't
know
whether
you
know
set
the
parent
to
null
or
the
child
will
no
longer
appear
in
the
child
collection
right
and
for
correctness.
Probably
only
one
of
them
will
work
right,
so
I
don't
know
how
I
would
use
this
and
make
sense
of
the
output
of
this.
K
Let's
see,
okay,
so
in
in
your
in
your
example,
the
children
will
not
operate
or
not
include
the
part
in
the
payload
right,
because
that's
where
the
reference
loops
detected.
F
If
you
take
something
like
a
binary
tree,
that
also
has
a
parent
reference.
If
you
start
with
the
root
node,
it
already
had
null
for
parent,
it
goes
to
write
down
a
child.
The
parent
is
already
in
the
object
graph.
So
then
parent
becomes
null.
Everything
makes
sense.
What
gets
really
weird
is,
if
you
do
the
left
child
of
the
root,
because
then
it
will
write
down.
F
So
if
you
start
from
a
root
of
a
tree,
everything
makes
sense
in
a
graph.
It's
wherever
you
ended
up,
but
the
yeah
changing
the
length
of
a
list
does
feel
weird
and
now
it
feels
like.
Maybe
sometimes
you
want
to
actually
insert
the
word
null
like,
which
maybe
breaks
an
assumption.
Yeah
all
right
now
we're
back
to
why
this
is
a
controversial
feature,
cool.
A
Yeah,
I
think
that's
why
I
said
last
time
like
it
makes
more
sense
to
me
that
somebody
has
to
put
jason
ignore
on
the
places
where
they
want
to
break
the
cycle
right
yeah,
but
like
yeah,
I
mean
I
understand
it
like
that's
how
json.net
works
today
right.
So
if
your
code
already
works,
I
can
see
that
being
convenient,
but
like
as
an
author
of
a
library,
I
would
be
not
very
eager
to
use
it.
M
K
If
I
remember
correctly
java,
the
the
libraries
for
java
doesn't
have
any
weird
semantics
that
as
preserved,
so
they
so
the
the
coder
needs
to
add.
Json,
ignore
properties
manually
to
each
property
that
will
cause
a
loop,
that's
one
and
for
girl
for
goalies
there's.
There
is
no
order,
workaround
right
or
tan
throwing
exception
when
the
reference
loop
is
is
detected
in
order
to
avoid
stack
overflow,
they
just
throw
or
recover
a
recoverable
reception.
M
Or
we
go
specifically
and
say,
like
I
think
maybe
I
may
have
missed
this,
but
I
think
someone
said
that,
like
let's
say
newtonsoft,
does
it
a
certain
way
and
we
say
and
the
property
isn't
preserve
or
ignore
a
cycle?
It
is
newton's
off
compact,
like
it's
very
explicit.
It's
like
this
is
a
quirk
for
compatibility,
not
necessarily
a
conceptual
idea.
L
A
M
K
F
K
I
see
not
really
because
we
don't
have
anything
so
okay.
So
that's
also
another
downside
that
I
wrote
just
right
after
the
risks
is
that
yeah
you
can
extend
the
reference
handler.
No
about
that
you
can.
You
can
extend
reference
handler,
preserve
semantics
and
handle
it.
I
mean,
and
you
can
create
your
own
referential
solver
class
to
handle
with
all
that
stuff
that
is
happening,
but
I'm
using
right
now,
I'm
just
using
an
internal
flag
to
discriminate,
whether
we
use
preserve
or
ignore
semantics
right.
K
A
B
K
Not
really
because
when
you
do
get
reference
like,
for
example,
let's
say
that
you
are
you
you.
When
you
look
at
reference,
you
already
wrote
the
property
name,
so
you
are
not
able
to
to
ignore
it.
But
well
you
could
write
null,
maybe
or
something
like
that,
so
it
will
be.
J
F
You
said
the
problem
is
you've
already:
output
to
the
output,
the
name
of
the
property
to
the
stream.
So
now
you
have
to
write
the
word
null
yeah,
but
what
if
you
called
the
handler
before
you
wrote
the
property
name
to
decide
not
to
write
it.
F
I
think
you
would
just
need
to
save
the
property
name
somewhere
call
the
handler
if
it
returned
the
don't
write
me
down
value,
then
not
write
it
down
and
otherwise
write
down.
The
answer
like
it
seems
without
seeing
the
code
and
how
far
apart
the
two
things
are,
it
seems
doable
also,
if
you're
outputting
to
something
rewindable.
You
just
need
to
revert
your
position
a
little
bit
and
then
start
writing
again
where
the
previous
property
had
been.
G
F
What
you're
modeling
so
I
mean
it
seems
it
seems
like
a
solvable
problem
to
make
it
where,
if
in
reference
handler,
if
we
add
a
const
somewhere
of
that,
the
reference
id
is,
you
know,
do
not
omit
or
something.
And
if
you
return
that
that
we
just
don't
write
the
thing
down
or
null
or
whatever,
because
I
don't
know
if
it'll
make
sense
already.
K
A
G
Sorry,
like
you're,
saying
it
wouldn't
be
possible
to
write
a
reference
handler,
even
if
you
could
return
like
omit
property
from
get
reference
to
do
this
is
that
the
claim
that
it
wouldn't
be
possible
to
do
json
ignore
cycles
as
a
customer
reference
handler.
A
Yes,
today,
you're
not
able
to
do
that,
because
the
reference
handler
doesn't
have
the
ability
to
do
that
right.
The
reference
handler
only
constructs
a
reference
resolver
and
the
resolver
is
basically
just
a
thing
that
you
know
has
a
very
simple
api
that
you
know
given
an
object,
gives
you
a
string
id
and
given,
given
the
string
id
gives
you
back
an
object
right.
So
that's
the
that's.
The
only
interaction
model
we
have,
and
so
there
is
no
notion
for.
Do
you
want
to
ignore
this?
A
A
B
A
Or
we
have,
or
we
just
change
the
symmetrics
of
get
reference
and
make
it
nullable
right
and
then
say
like
yeah
the
the
thing
that
calls
the
api
today
would
have
to
be
able
to
do
the
thing
and
just
drop
the
thing
on
the
floor
then,
but.
A
No,
I
no,
I
wouldn't
know
whether
there's
a
cycle
right,
because
you
know
whether
you
saw
the
object
before
it's
just
that
you,
like
the
handler
or
the
resolver,
still
doesn't
have
any
control
over
how
the
graph
is
being
traversed
right.
So
you
still
don't
have
the
context
of
like
what
was
the
path
that
it
was
requested
through
right.
You
would
just
say
you
know
the
the
the
the
serializer
walks
the
object
graph
in
some
order
and
then
the
best
you
can
do.
A
Is
you
say
if
I
see
the
object
again,
I
drop
it
on
the
floor
right
so
that
so
so
you
have
no
notion
of
saying.
Oh.
If
the
reference
comes
to
this
edge,
then
I
do
something
differently,
whether
it
comes
to
the
other
edge
right
and
that's
the
kind
of
thing
that
I
think
aaron
mentioned
earlier.
Like
you
know,
do
we
have
confidence
that
the
way
our
serializer
traverses
the
object
graph
is
the
same
order?
Ambition.Net
reverses
the
object
graph
and
the
answer
is
probably
no.
G
But
for
in
this
part
I
missed
earlier
and
if
it's
too
complicated
explain
fine,
but
as
far
as
ignoring
cycles
is
concerned,
why
does
the
order
you
traverse
the
craft
matter
like
it's
either
a
parent
or
it's
not.
A
Well,
I
guess
it
depends
on
what
you
want
the
outcome
to
look
like
right,
like
as
jeremy,
and
I
was
discussing
earlier.
It
kind
of
depends
on
where
you
start
your
traversal
right
like
so.
If,
if
you
have
a
tree
right,
you
have
an
intuition
that
you
say
you
know,
you
know.
Children
are
always
there,
but
parents
may
not
be
because
that's
that's
logically,
the
back
pointer
right,
but.
G
G
Goes
back
to
the
whole
dropping
object,
you
just
serialize
right,
so
the
root's
always
the
same
like
for
any
given
object.
A
F
So
you
start
from
the
same
route
and
then,
if
we
hit
skip
10,
then
we
write,
root,
skip
10
and
then
now
we
have
every
10
and
then
from
those
now
we
have
the
like
the
slices
of
9
that
go
forward
for
what
the
the
path
to
get
there
was
versus.
Newton's
off
jason
may
have
produced
root
next
next
next,
next,
next,
next
next
and
all
the
skeptics
are
null.
G
A
A
So
yes,
you
would
only
expect
in
the
you
know
the
the
list
has
ten
elements
and
then
you
basically
have
the
ten
elements
in
the
in
this
in
the
class
output.
But
do
you
expect
always
the
next
to
be
said,
or
do
you
expect
sometimes
next
to
be
said
num
times
previous
to
be
said,
right
like
you,
you
want
the
consistent
outcome
right.
A
And
yeah,
that's
why
I
said
to
me:
it's
a
I
don't
know
how
you
reason
about
the
output
of
it.
I
mean
if
you
only
care
about
the
objects
being
there
or
not
there,
and
then
sure,
but,
like
you
generally
care
about
which
properties
I
said
right.
So
that's
and
that's
where
I
have
trouble
with
this
policy
of
saying
ignore
cycle,
because
it
seems
to
me
arbitrary
right.
C
I
mean
this
is
a
non-standard
usage
of
json
right.
This
recycle
handling
so,
who
are
we
compatible
with
is,
is
unpredictable
output
going
to
change
how
newtonsoft
deserializes
our
objects
like?
I
don't
think
that
having
byte
compatible
output
is
necessarily
something
that
matters
because
you're
already
making
it
significantly
more
intended
for
machine
processing
and
not
necessarily
for
reading.
F
I
think
the
concern
would
be
more
like
newtonsoft
isn't
going
to
know
how
to
rehydrate
the
links
inherently.
But
if
you
were
using
a
doubly
linked
list
with
newton's
off
jason
and
you
found
when
you
serialize
it,
it
always
sends
next
and
never
and
prev
is
always
null
because
you
would
have
always
been
in
a
cycle
at
that
point,
that
you
build
up
a
thing
that
that
reruns,
the
linking
and
you've
written
the
code.
F
And
now
you
you
get
a
payload
from
us,
because
you're
trying
to
change
which
tech
you're
using
and
now
that
crashes,
because
it
turns
out
that,
due
to
the
order,
we
walked
the
properties
we
always
saw
prev
and
never
saw
next
or
somehow
magically
it's
because
of
subclassing,
some
of
them
set
prev
and
some
of
them
set.
Next
and
now
you
have
no
idea
what
to
do
so.
M
I
think
in
the
actual
issue
there
was
like
this
exact
problem.
Someone
tried
to
do
this
with
entity
framework
and
you
know
like
the
whole,
like
the
whole.
The
whole
issue
here
is
json
should
be
able
to
be
the
lingua
franca
between
the
the
contract,
the
you
know,
it's
the
contract
definition
and
it
by
not
adhering
to
what
json
is
actually
good
at,
but
by
enriching
it
with
its
own
concept
of
this
referential
thing.
That
literally
doesn't
exist,
we're
creating
json
x
and
if
everybody
doesn't
respect
json
x
for
how
to
represent
a
graph.
M
M
A
A
Cooked
up
our
own
scheme
on
like
how
we
refer
to
objects
right
and
I
think
it
was
inspired
by
what
jason.net
does
or
it
might
even
be
identical
right,
because
it's
just
a
pseudo
syntax,
where
we
save
special
property
names
with
prefix
of
dollar,
sign
right
to
indicate
that
and
but
but
that
to
me
is
kind
of
orthogonal.
My
question
is
more
like:
given
an
object
graph,
you
run
the
object
right
through
the
serializer,
then
to
the
d
serializer.
A
Can
you
reason
about
the
resulting
object
graph
and
I'm
saying
maybe
when
you
say
ignore
cycles,
you
can't
really
do
that
because
it
seems
arbitrary.
What
is
after
what's
null
and
which
ones
you
know
and
which
ones
aren't
and
that
to
me
seems
problematic
right,
because
even
if
you
abstract
the
wire
format
entirely,
it
seems
like
you.
You
know
you
put
your
your
your
objects
into
a
thing
that
you
know
almost
arbitrarily
drops
data
and
then
the
question
is:
did
you
expect
that
data
to
be
dropped
or
did
you
expect
other
data
to
be
dropped?
K
Entity
framework
has
this
problem
right,
as
you
mentioned,
and
given
that
they
have
these
bike
pointer
properties
like
they
have
ideas
of
the
parent
of
the
child,
or
they
have
a
list
of
childs.
It
doesn't
matter
it
does
it.
They
don't
suffer
from
the
loss
of
data
that
ignore
causes
right.
A
F
The
thing
that
scares
me
the
most
about
adding
it
as
having
talked
about
it
for
a
little
bit
is
the
order
we
walk.
The
properties
right
now
basically
can
never
change
in
the
serializer
like
if
it's
currently
alphabetizing
it
can't
change
to
do
the
order
that
they
happen
to
be
emitted
in
the
il.
F
If
it's
alphabetizing,
it
can't
do
the
order
that
a
source
generator
felt
like
spitting
them
out
unless,
like
that
order
has
to
say
like
because
if
somebody
does
try
writing
together,
some
wire,
this
backup
logic,
a
new
version
of
the
package
coming
in
because
of
transitive
dependencies
and
changing
which
things
happen
to
get
walked.
First,
therefore,
where
the
nulls
appear
will
destroy
them.
G
So,
okay,
I
do
feel
like
really
dense
here.
Can
someone
in
the
issue
perhaps
like
write
an
example
object
where,
if
you
had
like
the
you
know,
emit
cycle,
you
would
come
up
with
like
two
different
possible
serializations
based
on
the
walking
order,
because,
like
I'm
thinking
about
the
w
linked
list
scenario
and
like
there
could
be
a
lot
of
duplication
right
starting
from
head,
you
know
you
could
basically
repeat
each
element
twice,
but
eventually
yeah.
I
don't
know.
But
if
someone
could
write
a
comment,
that'd
be
great.
G
G
G
F
Stefan
think
of
the
doubly
linked
list
right,
so
you
have
a
private
next,
so
you
write
down
the
first
element,
whatever
you
consider
the
first
element
to
be
the
thing
that
you
pass
to
the
serializer
if
it
walks.
F
If
the
serializer
sees
next
as
the
first
property
to
write
down,
then
in
the
object
it
writes
down.
Second
prev
will
be
null
because
prev
has
already
been
written
in
this
object
stack,
but
if
it
happens
to
hit
prev
before
next,
then
prev
is
set
and
then
prev's
next
is
null.
F
G
I
don't
get
so
you
say
you
have
the
the
head
right
and
it
has
private
next
so
for
the
root
object.
Both
previn
next
won't
be
null
assuming
that
it's
not
linking
to
itself
trivially
and
then
for
the
prev
right.
The
prev's
next
will
be
null
and
for
the
next
the
next
pres
will
be
null,
but
so
like,
but
that's
deterministic,
no
matter
which
order.
I
walk
it
in.
A
Well,
so
now
so
so
imagine
you
have
a
linked
list
right,
a
b,
c
d
right
and
then
you
have
a
root
object
that
that
refers
to
the
first
element,
but
now
the
root
object
also
refers
to
the
last
element
right.
So
you
have
the
first
and
the
last
right
now.
The
question
is:
if
you
serialize
this
outcome,
you
can.
You
can
now
traverse
the
list
either
going
through
the
first
and
then
you
go
next
next
next
or
you
can
reverse
the
list
with
going
last
impress
prefpref.
A
A
Well,
no
because
it
so
if
you
serialize
this
root
object
that
that
has
the
first
last
and
the
pointers
right.
The
question
is
now
well,
you
do
you
find
an
object
graph
where
first
is
set
to
non-null
value,
and
then
all
the
next
pointers
are
populated
or
do
you
you
get
a
first
that
is
now
and
the
last
that
is
non-northern.
All
the
previous
ones
are
populated
right
because
they
both
will
serialize
like
that
they
will
both
be
valid
outcomes
with
that
algorithm
it
depends
on
which,
but.
G
G
F
F
G
F
F
No,
so
it's
you
have
the
doubly
linked
list.
If
we
see
prev
first,
then
you
write
root
or
you
write
element
that
you
saw
and
then
prev
prev.
Each
of
those
prev's
have
another
prev,
but
don't
have
a
next,
because
the
next
was
already
written
in
this
stack
and
then,
if
in
the
next
version,
something
changes
about
the
order
that
the
serializer
sees
the
properties.
F
And
now
it
writes
next
your
code
that
already
understood
how
to
link
things
because
prev's
were
set
and
next
weren't
assume
it's
degenerate,
and
you
have
a
cyclical
double
a-link
list
that
you
know
you.
You
wrote
the
code
to
wire
things
back
up
and
now
you're
getting
nulls,
because
it
saw
the
other
property
first,
but.
F
G
F
I
guess
yes,
in
the
case
of
a
doubly
linked
circle
from
the
root,
it
would
write
the
whole
list
out
for
each
path.
Each
one
would
just
not
know
about
the
other
or
the
the
parent
correct,
and
you
could
never
like
recreate
the.
F
Yeah,
it
still
feels
very
it.
The
problem
is
when
there
are
multiple
paths
to
get
to
it,
to
a
thing,
through
the
same
stack
that
that,
where
the
whichever
one
you
hit
first
makes
things
become
null
randomly
and
that
feels
problematic,
and
why.
A
A
A
G
But
what
I'm
pointing
out
is
like
when
you
serialize
right,
like
from
a
given
route
like
that
search
or
breadth.
First
search
you're,
trying
every
single
path
and
on
a
given
path.
It's
either
a
parent
or
it's
not,
and
I
guess
that's
the
part.
I
don't
understand
like
if
you're
trying
to
serialize
every
single
path,
there's
either
a
cycle
on
that
path
or
there's
not.
A
Right
so,
like
I
think,
I
think,
that's
I
think
that's
well
defined
whether
you
have
a
cycle
or
not
right
that.
But
but
the
problem
is
ignore
cycle
says
the
first
time
you
detect
the
cycle,
you
break
it,
but
there's
multiple
different
ways:
how
you
can
break
the
cycle
and
that's
resulting
in
this
ambiguous
outcome.
G
G
A
That's
basically
what
I
what
I
what
I
what
I
said
earlier
with
this
example
of
you
have
a
root
object
that
has
first
and
last
for
linked
list
right,
because
if
you
first
go
through
the
first
pointer
and
then
you
go,
you
know
next
next
next,
you
have
a
different
result.
If
you
go
through
lost
and
you
go
pre-prep.
G
A
But
I
don't
understand
what
you
mean
by
you:
try
everything
in
the
past,
because
that's
not
what
we
do
right.
We
just
we
just
do
the
walk
and
then
the
first
time
we
see
an
object
again
as
we're
serializing
it.
We
drop
it
on
the
floor
exactly
and
I'm
saying
that's
deterministic,
but
maybe
it's
not,
but
well.
It's
deterministic
like,
depending
on
the
order
in
which
you
read
it
right
so.
G
K
Yeah,
I
don't
think
that's
true
hold
on
I'm
not
sure
if
I'm
understanding
the
concern
but
to
to
respond
to
stephen
the
dictionary,
for
example,
it's
non-deterministic.
So
when
you
still
as
a
dictionary,
the
elements
might
be
might
come
in
a
non-deterministic
way.
So
that's
how
you
might
end
up
with
different
results.
G
K
K
Yeah
yeah,
it's
it's
been
a,
I
don't
know
when
they
introduced
it,
but
yeah
it's
been
sitting
there
for
a
long
for
a
lot
of
time.
That's
why
people
is
asking
for
something
like
that,
because
they
don't
want
their
fellows
to
have
all
these
weird
news
and
well
weird
semantics
that
they're
not
so
used
to
them
and
also
because,
like
for
example,
if
they
send
json
to
javascript,
they
need
something
else
to
to
be
able
to
understand
the
semantics.
F
Then
you
should
end
up
with
a
lot
of
duplication,
but
nothing
nothing's,
nothing
complicatedly
surprising,
so
in
the
doubly
linked
list
or
emo
in
your
case,
where
you
have
first
and
last,
and
it's
doubly
linked
first
and
last,
both
write
down
the
whole
graph
where
first
writes
down
everybody
with
the
next
pointer
and
last
writes
down
everybody
with
a
private
pointer,
and
it
was
just
a
it
repeated
every
note
except
except
the
root
the
in
a
in
a
cycle.
F
It's
whatever
you
start
and
it'll
walk
both
ways
until
it
hits
back
to
itself
again,
it's
massive
duplication.
F
F
F
F
F
K
The
yeah,
the
reason
for
that
is
that
when
I
was
testing
newton's
of
and
where
you
are
able
to
combine,
both
features,
preserve
and
ignore
you
get
somewhere
as
an
artist
right
like,
for
example,
what
what
happens
to
me
first,
do
you
preserve
first
and
you
emit
the
ref
or
do
you
detect
cycles?
First,.
K
F
Yeah,
the
only
part
that
does
feel
like
it,
maybe
once
more
thinking
is
for
something
like
you
know,
a
dictionary.
Should
it
write
down
the
key
that
now
had
a
a
reference
cycle
and
then
say
null
if
it's
a
list,
should
it
change
the
length
of
the
list
or
should
it
write
down
the
word
null
the
like
disappear,
this
property,
even
if
ignore
null
is
true,
feels
really
weird
in
a
in
a
list
unless
ignore
null
is
already
removing
items
out
of
lists.
K
I
don't
know
if
writing
null
is
something
better
than
ignoring
it,
because
you're
I
mean
you
were
already
changing
the
payload.
Why
adding
would
be
better.
F
Well,
because
if
you
have
a
a
structure
that
has
the
array
of
data
and
a
you
know,
how
many
items
should
I
see
like
you
wrote
down
six
items
and
then
the
list
was
only
five
items,
long
versus
if
there
was
a
null
in
the
middle,
like
that's
a
thing
that
you
could
handle.
F
G
F
G
F
You
send
here's
the
state
of
the
world
which
includes
a
list,
and
you
say-
and
I
want
item
three
well
if,
if
item
two
happened
to
be
an
object
cycle,
then
you
you'd
no
longer
want
three.
You
now
want
two,
because
what
got
transmitted
on
the
wire
and
what
the
world
looked
like
to
you
weren't
the
same
thing:
the
the
indexes
after
a
dropped
reference,
all
change.
F
F
A
F
Maybe
it
depends
on
how
complicated
your
your
world
state
is
like
if
you
have
a
list
of
things
which
can
contain
a
a
quote-unquote
parent
object,
and
you
have
a
I'm
the
selected
element
in
the
ui
index
three
and
but
now
that's
an
out
of
bounds
because
the
you
removed
a
previous
item.
Like
that's
weird.
G
Yeah,
I
think
you
know,
dealing
with
cycles,
is
always
going
to
be
weird
to
to
some
extent
most
of
the
time
cycles.
I
think,
are
going
to
be
directly
in
properties
and
not
unless,
but
I
think
I
mean
there
will
be
behavior
right
like
you,
either
replace
the
cycle
with
null
or
you
admit,
the
property,
and
if
it's
an
all
you
put
on
the
list
and
if
it's
submit
property
I'd
remove
the
item
from
the
list
for
consistency.
F
Yeah
so
I
mean
yeah,
it
may
make
sense
to
just
say,
treat
it
as
null
and
if
we
skip
null
items
and
lists
when
writing
them
down,
then
that's
already
a
weird
behavior
we
have,
and
that
makes
sense.
I
doubt
we
do
that
if
lists
even
in
ignore
null
say,
write
down
the
word
null.
As
that
was
the
third
item
in
this
array,
then
this
should
write
down
the
word
null.
F
A
F
A
My
question
is
like:
why
do
why
does
anybody
want
ignore
cycles.
F
G
F
Right
the
really
ignore
cycle
is,
you
didn't
think
about
your
data
model?
You
probably
meant
to
be
sending
identifiers
and
instead
of
sending
identifiers,
you
send
objects
and
that
when
somebody
clicks
a
button,
you're
sending
them
like
a
gig
of
data.
So
really
it
means
you're
doing
it
wrong,
but
people
don't
like
to
use
it.
F
G
F
G
A
Right,
I
mean
I
mean
I
think,
strictly
speaking,
the
correct
fix
would
be
just
mark
your
back
pointers
as
json,
ignore
and
then
have
them
patch
up
right.
That
will
be
the
ideal,
in
which
case
you
don't
write
a
ginormous
output
and
you
have
total
control
over
what
you
want.
If
you
don't
want
to
do
that,
then
yeah,
maybe
you
know.
A
Presumably
you
know,
assuming
that
we
can
have
a
deterministic
outcome
which
it
sounds
like
we
can
then
yeah
you
just
do
the
big,
the
big
switch
and
say
ignore
cycle
and
live
with
the
outcome
that
that
produces.
F
Which
is
definitely
different
than
the
existing
reference
handling
feature
but
yeah
my
opinion,
which
is
being
written
in
an
archive
right
now,
is
anybody
who
wants
this
feature
is
doing
serialization
wrong,
like
they,
they
meant
to
serialize
ids.
Instead,
they
sent
their
whole
object
graph
and
I've
seen
that
on
various
web
properties.
You
look
at
like
how
much
data
was
transmitted
when
you,
you
know
selected
an
item
and
it's
like
there
was
some
flight
dispatch
software
that
I
was
using
that
you
know
looking
at.
F
G
I
I
know
in
the
like
legacy:
signalr:
we
used
noon
soft's
ignore
cycle
functionality
because
you
know
you're
lazily
serializing
to
like
a
websocket
or
whatever,
and
when
a
websocket
was
detected,
we
didn't
want
to
kill
the
entire
websocket
connection
because
we
couldn't
like
close
out
the
json
object
or
whatever
yeah
I
don't
know
like
so
we
kind
of
made
the
decision
for
our
users.
It
might
have
been
better
to
air
out
in
that
case,
but
just
kind
of
an
instance
for
where
that
was
used.
A
A
So
then
it
seems
like
we
all
agree
that
this
feature
is
unfortunate
but
like
there
also
doesn't
seem
to
be
any
sort
of
shop
ship
stoppers
for
that
either.
F
F
F
A
F
F
F
Right
and
like
part
of
this
comes
back
to
if
you,
if
we
have
a
a
list
right
now
or
an
array
or
you
know
whatever
do
we
write
down
nulls
even
when
ignore
null
is
set
to
true?
If
yes,
then,
we
should
write
null
in
these
cases
if
we
would
skip
them
because
ignorance
was
set
to
true,
then
I'm
sure
skip
them.
I
guess
or
we'll
get
a
new
ignorant
flag
of
ignore
null,
except
for
duplicate
references
and
a
list.
F
So
right
now,
if
you
serialize
and
you
have
whatever
the
ignorant
thing
is
set
to
true
and
one
of
the
properties
is
a
non-null
array
or
list
or
whatever
that
has
a
null
value
in
it.
Do
we
write
down
the
word
null,
even
though
ignorance?
That's
true,.
K
A
D
G
G
M
M
It's
it's.
I
mean
it's
going
to
be
simple,
mainly
because
everybody
here
is
going
to
roll
their
eyes,
because
it's
calm
that
that
is
true,
they're,
just
like
yeah.
We
don't
care,
leave
me
alone,
like
that's,
usually
what
I
get
out
of
this
conversation,
but
that's
fine.
I
I
can
wait.
It's
entirely
up
to
y'all.
M
F
Normal
overload
suggestion
is
that
new
parameters
go
at
the
end.
Does
this
one
have
to
be
inserted.
F
M
F
F
D
F
M
It
does
make
sense
only
because,
yes,
it
it
does
make
sense
because
they
represent
well.
I
guess
yeah
you're
right.
It
doesn't
technically
matter
yeah.