►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
I'm
really
curious
what
is
going
on,
because
the
funny
thing
really
is
is
that
I,
on
my
end,
every
diagnostic
window.
I
have
here
whether
it's
encoding
or
the
networking
thing.
It's
all
fine.
I
just
see
that
it
keeps
dropping
the
connection
to
the
to
the
restream
server.
I'm
really
curious.
What's
going
on
and
the
restream
side
is
just
claims
that
it
doesn't
receive
data.
A
B
I
mean
it's
just
so.
We
have
a
bunch
of
methods
that
are
like
export
subject:
public
key
info,
which
returns
a
byte
array
and
then
for
all
of
the
things
that
have
standard
pim
encoding
headers.
It's
add
a
string
version
of
it
that
then
ends
in
pim.
B
A
B
B
E
Sure
merrick's,
recognizing
that
pretty
much
every
call
site
for
object,
disposed
exception
follows
one
of
these
four
patterns
getting
a
name
from
somewhere
and
passing
it
to
the
instructor,
not
frequently
it's
a
call
to
get
type
and
he's
suggesting
that,
rather
than
doing
that,
we
could
add
an
overload
that
takes
basically
this.
So
you
know
you'd
say
new
object,
dispose
exception
this
and
the
implementation
we'd
pick
one
of
these,
the
top
three
things
to
standardize
on
and
it
would
use.
E
D
F
E
What
the
standard
eyes
on
we
would
have
to
because
the
implementation
is
going
to
have
to
do
it.
Oh,
do
you
mean
like
we
in
this
room,
yeah?
No,
whoever
influenced
it
would
need
to
which
would
most
likely
be
a
survey
of
all
the
call
sites
we
can
find
and
pick
the
most
common.
C
E
That's
a
good
question
steven
screw
those.
D
E
D
B
E
B
A
B
E
I
see
what
you're
asking
I
think,
it'll
give
you
an
ambiguity.
D
B
B
A
B
G
Should
you
know,
should
we
have
a
overload
that
takes
type
for
these
scenarios,
where
you
have,
for
example,
a
disposable,
struct
or
other
objects?
I
know
it's.
The
the
cost
of
boxing
isn't
really
a
concern
if
you're
throwing
an
exception,
but
most
of
these
come
down
to
what
you
actually
want
is
the
type.
A
C
E
B
Honestly,
that's
where
I
thought
that
the
suggestion
was
going
so
it
it
makes
sense
to
me
because
the
the
message
you
get
out
of
object,
dispose
exception
is
object.
Name,
colon
space
quote
the
string
you
give
close
quote.
B
So
if
we
accept
a
thing
that
passes
in
type,
that
would
basically
be
that
the
object
one
is
effectively
calling
the
other
overload
with
object
type
and
it's
just
being
like
yup.
The
string
that
we
generally
expect
here
is
a
type
either.
We
can
pull
it
off
your
object
or
you
can
pass
in
type
of
your
own
name
or
whatever.
G
Maybe
you
have
another
type
that
you
want
to
use
instead
of
the
like,
for
example,
you
have
an
internal
type
and
you
want
to
use
the
the
public
facing
type
instead.
G
So
let's
say
let's
say
you
had
an
internal
exception,
type
or
or
maybe
exception's
a
bad
bad
example,
but
maybe
you've
got
an
animal
class
and
then
you've
got
you
know
a
hidden
tiger
class
and
you
really
want
to
you:
don't
want
it
to
be
type
of
tiger.
You
want
it
to
be
type
of
animal
instead,
because
you
don't
want
to
expose
that
quote-unquote
internal
type
name.
C
B
G
Yeah,
it
doesn't
seem
like
it's
a
critical
scenario,
but
it
seemed
like
something
that
was
worth
asking
considering
that
that's
functionally
what
the
object
api
we're
exposing
is
going
to
do,
and
so,
if
we're
already
going
to
functionally,
have
a
have
an
api,
that's
functionally
you
know
get
type
full
name.
Then
maybe
we
should
just
have
a
api
that
takes
type
directly
and
then
just
full
name
on
that
as
well,
but
I'm
not
hardset
on
it.
G
So
I
can
talk
to
this
one.
This
is
related
to
the
dependent
handle
api
that
we
approved
and
was.
A
The
good,
but
if
this
thing
is
tied
to
something
else,
the
underlying
collection
might
change
today
we
only
have
an
overload
that
takes
a
an
eye
list,
and
so
people
were
saying:
that's
not
really
reasonable.
Sometimes
you
only
or
you
all
you
have
is
a
read
only
list
so
could
we
just
have
an
overload
that
takes
an
already
only
list
rather
than
having
to
implement
ilist?
A
A
A
E
B
D
G
B
A
A
B
Have
to
coalesce
well,
it
can't
coalesce,
because
there's
no
unifying
implementation
behind
them
it'll
have
to
make
each
thing
right.
Now,
that's
just
a
forward
or
be
a
if
this
one's
null
call
the
other
one
forwarder.
A
B
B
G
G
Right
because
read
because
read-only
list
implements
read-only
collection
and
list
does
not
implement
face
dispatch
right,
but
inter,
inter
checking,
interface
dispatch
is
not
necessarily
as
expensive
as
walking
the
list
of
interfaces
that
a
type
implements
to
determine
is.
Is
it
implementing
one
of
these
interface
types?
You
could
also
just
have
two
fields.
B
A
No,
it
will.
I
mean
like
it's
just
that
these
collections
are
not
super
lightweight.
To
begin
with,
like
you
know,
they're
all
virtual
right,
every
every
single
method
you
can
call
is
virtual.
You
can
derive
from
them
right.
They
are
more
heavyweight
than
list
of
t
or
dictionary
right,
so
they're
not
super
optimized
for
perv
already.
B
F
A
No,
so
the
problem
is,
we
have
two
kinds
of
types
we
have
the
you
know.
We
have
inimorable
ilist
eye
collection
and
those
were
designed
on
day
one
to
have
a
mode
called
read
only
right.
So
there's
a
read-only
property
and
if
that's
returning
true,
then,
if
you
call
any
mutation
apis,
it
would
write.
But
but
if
your
code
only
accepts
an
interface,
you
say
you
get
an
irid-only
list
of
t
from
somebody.
Well,
it's
not
guaranteed
that
this
also
implements.
A
F
B
A
You
can
even
do
that.
I
mean
that's,
not
unreasonable
right,
we
could
say
we
we
provide
these
wrappers
in
a
centralized
place,
so
we
could
say
we
have
a.
You
know
I
collection
from
an
eye
with
only
collection.
We
have
an.
I
read
only
list
from
an
eye
list
right
and
then
we
can
just
say
yep
if,
whenever
when,
whenever
you
have,
this
mismatch
call
this
centralize
the
api
that
gives
you
the
wrapper
for
the
other
side,
I
mean
that
wouldn't
be
bad.
A
But
basically,
if
we
do
that,
we
wouldn't
do
this
api
either,
but
we
would
just
say:
there's
a
maybe
we
make.
Maybe
we
make
them
extension
methods
so
they're
more.
I
guess
as
list
on
something
that
is,
I
read
only
list
and
if
the
instance
already
is
a
list,
you
just
return
that
one
right
I
mean
we
could
just
define
those
methods,
as
you
know,
not
doing
double
wrapping.
Basically.
B
Okay,
so
basically
yeah
I
mean
you
would
still
have
then
the
interesting
question
of.
Sometimes
you
see
for
each
of
the
three
things:
potential
types
and
not
just
read-only
collection,
because
there's
also
a
collection
of
tea,
which
is
a
list
of
tea
and
not
a
collection
of
tea,
because
we're
good
at.