►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
Hello,
everyone
we're
a
little
bit
late
today,
but
we'll
see
what
we
can
get
through.
A
As
usual,
the
number
of
red
items
has
grown
and
we
will
do
our
best
to
shrink
it,
but
we
don't
expect
to
accomplish
that
today,
or
rather
we
don't
expect
to
annihilate
them
today
and
now
I'm
already
rambling.
So
instead
of
me,
rambling,
let's
just
move
on
and
get
started
so
logger
messages.define
up
to
14
arguments,
509.13
miriam.
B
C
D
D
The
main
motivating
factor
for
this
is,
I
think
we
spoke
to
martin
and
folks,
who've,
been
you
know,
building
the
r9
libraries
and
ergo
helping
deploy
it
in
like
hundreds
of
applications
and
it's
it
seems
perfectly
reasonable
because
they're
using
it,
the
the
fear
last
time
was
about
the
you
know,
the
combinatorial
explosions
that
we
get
from
like
14
genetics,
but
the
the
actual
like
blurt
in
like
jittery
chord
views
just
is
wouldn't
be
that
much
because
you
know
it
only
adds
to
the
like.
D
D
C
So
so
at
most
there
are
16
over
16
types
that
you
can
pass
on
and
since
we
have
lo,
I
log
or
an
exception
like
that,
like
I'm
gonna,
first
wait
on
to
see
what
your
comments
are
and
then
I'll
continue,
because
I
know
that
was
gonna
be
awesome.
E
So
I
was
just
laughing
because,
like
I
was
just
thinking
of
this
picara
meme,
there
are
four
lights
the
whole
time.
So
I
mean
I
think.
Last
time
we
just
said,
like
the
amount
of
overload
seems
excessive
because
you
needed
two
per
combination,
but
now
you
cut
it
down
to
just
one
yeah
I
mean
it's
still
like
I
mean
I
don't
know
like
the
problem.
With
these
kind
of
things
is
like:
what's
a
reasonable
number,
I
mean
you
need
more
than
six.
Do
you
need
12,
14
or
10
to
me?
C
C
Okay,
exactly
I
was
going
to
get
the
report.
No,
so
what
you
see
in
the
second
blob,
which
is
removing
a
bunch
of
stuff,
is
something
that
happened
during
60,
like
maybe
last
preview,
where,
rather
than
having
two
overloads
like
one
with
skip,
enable
check
rather
than
having
it
as
we
removed
the
skip,
enable
check,
but
rather
add
log
options.
C
A
G
C
So
the
generator
the
logging
generator
is
actually
using
defined
apis
under
this
hood.
One
goal
for
these
apis
is
to
make
sure
the
runtime
capabilities
match
the
compile
time
capabilities.
G
But
you
can't
do
that,
though,
because
you
can't
define
every
single
possible
signature
in
terms
of
funk,
like
you
can't
take
refs
trucks,
for
instance,
you
can't
take
pointers
like,
but
you
could
do
that
with
actual
source
generators,
and
you
can
do
that
with
user-defined
delegates.
You
just
can't
do
it
with
funk.
F
G
Box
things,
but
if
your
box
matters,
you
can't
bother.
H
G
Right
so
so
just
go
going
back
to
my
original
question,
which
remains
unaddressed,
which
was
so
if
I
have
a
source
generator
that
takes
actually
like
16
arguments
or
17
arguments
like
it's
just
going
to
blow
up,
because
there's
no
corresponding
defined
method.
C
Because
action
goes
up
to
16,
so
it
won't.
We
can't
we
can't
use
action
or
a
lot
any
longer
message.
Well,
the
answer
to
your
question
is
correct.
We
can't
we
don't
support
larger
than
14.
number
of
arguments,
but
that's
something
that
the
source
generator
would
be
able
to
provide.
C
G
F
F
C
Because
a
lot
of
the
time
we've
had
issues
come
up.
Maybe
I
have
a
link
to
one
where
there
was
an
api
edition
to
add
maybe
to
up
to
six,
but
they
were
like.
Can
we
have
eight
like
there
might
be
another?
But
but
if
we
have
like,
I
don't
know
14
if
we
have
like
even
like
10,
maybe
there's
way
less
request
for
it
like.
How
do
I
say.
G
No,
I
get,
I
get
the
concern.
What
I'm
trying
to
figure
out
is.
Is
there?
Is
there
a
way
to
solve
the
concern
without
introducing
a
whole
bunch
of
public
api?
If
the
answer
is
no,
then
the
answer
is
no,
but
it
sounds
like
you
were
saying
there
already
is
a
way
to
solve
it
and
we're
adding
the
public
api
just
because.
D
So
so
one
thing
libra
is
non-source.
Generators
also
use
this
public
api,
like
if
I
wasn't
interested
in
using
the
logging
source
generator,
and
I
just
wrote
a
log,
a
message
I
defined
myself.
I
may
have
like
nine
parameters.
I
think
what
what
was
said
before
is
right
now,
because
of
the
difference
in
the
compile
time.
You
know
the
these
apis
versus
the
source
generator
approach.
D
It's
sort
of
this
arbitrary
thing
where,
when
I
go
past
six
arguments,
I
have
to
switch
from
using
log,
a
messages
are
defined
to
using
the
source
generator
and
the
source
generator.
Like
has
a
fallback
right.
F
So
one
more
thing
that
does
concern
me
about
this
api
is
that
we
we're
returning
function,
action
and
it
kind
of
limits.
What
we
can
do
in
some
sense,
so
one
alternative
is
to
return
a
class
or
a
struct
from
this
from
these
calls,
so
we
can
do
more
in
the
future.
F
I
F
Yeah,
because
my
main
concern,
I
think
right
now
is
there's,
there's
two
kinds
of
overloads
here:
there's
ones
that
take
log
level
and
one
is
that
zone
I
think
yeah
exactly,
and
that
basically
adds
like
a
bunch
of
overloads
that
we
don't
that
aren't
ideal
and
we
could
probably
get
away
with
with
having
wanted
overloads.
If
we
took
in
options
and
we
returned
a
thing
that
could
have
messed
up
on
top.
F
That
way,
we
wouldn't
have
to
like
add
more
overloads
to
change
the
return
type.
E
I
mean
I
don't
know
how
much
we
care
I
mean
like
to
me
like.
If,
if
we
are
concerned
about
the
you
know
the
ugliness
in
terms
of
number
of
arguments
here,
I
would
argue
that
damage
has
already
been
done
by
the
existing
pattern.
We
just
try
to
make
it
self-consistent
at
this
point
right,
but
do
you
want
to
add,
like
forking.
E
E
Yeah
but
like
I
think,
what's
a
reasonable
number
right,
I
mean
like
every
time
you
said.
Like
you
know,
four
is
enough:
somebody
comes
with
five
or
six
you're
like
well.
Five
or
six
is
not
unreasonable
either
right.
So,
like
you,
try
to
pick
a
number,
that's
high
enough
that
you
can
say
yes,
okay,
if
you
need
more
than
14,
then
screw
you,
because.
G
Just
work
right:
well,
the
only
thing
too
is
if
you're
willing
to
use
refund
like
none
of
this
is
an
issue
because
you
just
have
someone
to
pass
the
actual
delegate
type
into
the
method,
and
then
you
just
emit
whatever
signature
is
required.
Like
end
of
story,
you
have
a
single
overload,
you're
done.
F
G
E
G
For
when
we
could
just
add
a
few
overloads
yeah,
it's
not
going
to
hurt
anyone.
It
is
the
more
future
proof
method.
That's
that's
the
thing
right,
because,
okay,
great
today,
six
isn't
appropriate,
but
six
isn't
sufficient,
but
14
is.
Are
you
going
to
come
back
next
year
and
say
well,
14,
isn't
sufficient.
F
C
And
the
follow-up
proposal
is
allowing
the
action
to
also
take
log
level
so
that
we
have
dynamic
log
level
support
and
the
reason
for
this
is
because
the
compile
time
source
generator
has
that
feature
but
define
the
runtime
define
api.
Do
not
allow
that
today.
A
F
J
F
A
C
I,
I
think,
was
it
jeremy
that
commented
or
emo
about
one
having
13
the
other
one
having
14
yeah.
A
A
C
Wait
are
you
saying
the
number
of
arguments
are
the
same.
A
C
C
A
There
does
anybody
have
feelings,
including
t14
david
seems
to
be
trying
to
completely
rewrite
the
feature,
and
I
think,
if
that's
the
answer,
then
we're
saying
needs
more
work
in
getting
back
to
terex
issue.
G
G
F
F
So
you're
saying
ignoring
the
log
level
thing
just
adds
extra
overloads
for
more
parameters.
G
Well
there
there
was
a
so
this
proposal
had
two
parts.
One
of
them
was
to
change
the
existing
signatures
to
take
an
options
struct
and
the
other
was
to
expand
the
number
of
overloads.
It
seems
like
we
should
at
least.
A
A
F
F
G
The
reason
I
suggested
that
is
because,
like
that's
how
reflection
works
all
the
way
up
and
down
like
we
don't
expose
tons
of
overloads
for
everything
we
make
the
caller
pass
in
the
delegate
type,
and
then
we
give
them
back
the
telegraph
that
way.
They
can
also
do
things
like
name
arguments
and
so
on.
But
but
you
know
within
the
runtime
we're
able
to
do
things
like
wrapping
that
pretty
cheaply
and
that
might
not
be
applicable
for
your.
B
Yes,
so
last
time
we
we
already
discussed
the
the
delegate
measurement
callback
and
we
discussed
the
instrument
published
callback
and
we
discussed
measured
measurement
completed,
so
we
stopped
at
enable
measurement
again
one.
So
if
you
remember
so,
the
listener
is
its
job
is
to
listen
to
the
to
the
measurements
that
published
by
the
instruments.
B
So
the
listener
have
this
enable
measurement
events
which
is
enable
the
listener
to
start
listening
to
some
specific
instruments,
and
when,
when
to
decide,
I
mean,
when
the
listener
decide
to
listen
to
any
instruments
they
can
pass.
This
state
object
object,
which
is
its
opaque
to
the
to
the
metrics.
In
general,
I
mean
this
state
object
is
going
to
be
called
back
when,
when
the
measurement
come
back,
I
mean
so,
we
can
pass
it
back.
B
B
The
second
one
is
disabled
measurement
events,
which
is
doing
the
the
opposite
of
that
I
mean
like
if,
if,
if
there
is
already
listening
to
some
any
specific
instrument
and
decide
to
stop
listening,
so
they
can
call
disabled
measurement
events,
so
this
is
basically
why
we
have
these
two,
the
the
next
one,
which
is
the
more
interesting
one,
which
is
this
set
measurement
event
callbacks.
B
This
is
the
the
callbacks
that
the
the
user.
B
B
K
B
Okay,
next
is
the
start.
This
is
so
when
you
create
listener
the
listener,
will
not,
it
would
be
inactive.
I
mean
like
it's
not,
it
would
not
do
anything.
I
mean
until
you
prepare
it
and
set
what
you
need.
Callbacks
initialize
it
completely,
and
then
you
call
start
so
when
you
call
start
it
will
activate
the
listener
to
the
system.
B
So,
basically,
when
you
call
start,
it
will
start
like
so
the
the
metrics
will
start
emulating
all
instruments
that
published
in
the
in
the
system
and
the
start
calling
back
like
you
know
any
swimming
published
for
this
listener
that
you
already
started
and
from
there
I
mean
the
listener
can
decide
to
to
enable
measurement
for
this
instrument.
B
B
So
if
you
remember
about
like
we
talked
about
like
we
have
two
type
of
instruments,
I
mean
like
the
regular
instrument,
which
is,
I
think
germany
called
the
stream
instrument
and
the
the
other
one
is,
which
is
we
call
it
observable
instrument
so
observable
and
instrument
which
is
like
you
can
call.
B
You
have
a
callback
that
you
call
this
instrument
when
you
want
to
get
the
measurement.
So
it's
not
calling
you,
but
you
are
calling
it
so
so
how
how
you
call
the
the
observable
instruments
through
the
listener
so
through
this
api,
so
record
observable
instruments.
B
So
basically,
if
this
listener
is
listening
to
one
or
more
observable
instruments-
and
you
call
this
ebi
recording
observable
instruments
so
the
listener
internal-
I
mean
it
will
go
to
every
instrument
observable
instrument
that
this
listener
listening
to
and
start
calling
to
get
the
measurement
from
it
and
then
reporting
it
back.
This
measurement
through
the
callbacks
that
you
set
inside
the
set
measurement
event
callbacks.
B
So
you
will
get
I
mean
like
so.
At
the
end,
I
mean
like
in
any
type
of
of
instruments,
is
going
to
get
the
measurements
through
the
exact
same
callbacks
that
you
created
hours.
You
you
passed
to
the
set
measurement
event
callbacks,
so
basically
record
observable
instrument
is
just
like
you
know,
going
through
all
observable
instruments,
calling
get
the
measurements
from
it
and
passing
back
to
the
to
the
callback
that
you
you,
you
already
initialized
it
with
the
set
measurement.
B
A
H
B
Which
stop
yeah?
I
mean
this
is
this
is
all
of
the
comments?
Sorry
I
mean
so
we
we
should
remove
the
stone
yeah.
It
should
be
disposed
actually
the
original
design
we
had
this
post,
I
mean
store
and
dispose,
and
we
found
like
you
know,
both
of
them
is
actually
doing
the
same
thing.
B
So
so
yeah
I
mean
like
just
ignore
the
last
part
of
calling
this
pose.
A
A
B
B
Yeah
we
have
the
same
idea.
Also
is
what
we
call
it
activity
listener
I
mean
like
which
is
listening
to
the
activities.
A
B
Yeah,
so
basically
the
instrument
is
doesn't
stop
at
all,
but
but
the
instrument
only
originally
is
created
from
what
we
call
it
meter,
which
is
like
a
factory
type
that
it
can
create
instruments.
E
B
B
Actually,
we
call
it
state
because
we
found
like
previously
there
is
other
classes
that
the
quality
state,
which
is
it
makes
a
lot
of
sense.
Originally,
we
called
it
cookie,
but
we
didn't
like
the
name,
so
we
changed
it
back
to
state.
G
That
makes
sense
you're
returning
it
from
the
stop
method
too,
which
was
or
from.
E
The
disabled.
B
F
Question
pretty
unfamiliar
with
this,
but
looking
at
the
measurement
callback
delegate,
I
notice
it
takes
t
measurement
what
what
is
t.
Oh,
it's
just
any
struct.
B
G
A
B
A
Sure,
but
right
while
we
try
to
minimize
our
breaking
changes,
the
rest
of
the
world
is
not
as
diligent
so
like.
Really.
This
is
because
this
is
basically
part
of,
but
if
we
think
of
this
as
a
login
component,
is
there
any
log
that
says
your
logging
wasn't
listening
to
the
login
correctly
like?
Is
there
some
way
that
somebody
finds
out
that
that
they're
not
quite
listening
to
what
they
thought?
That's
that's
really.
My
question.
B
B
A
I,
like
personally,
I
think
it's
going
to
be
really
hard
to
diagnose,
especially
if
your
listeners
listening
to
a
whole
bunch
of
events
of
like
not
not
seeing
that
you
didn't
register
along
or
you
see
a
bunch
of
stuff
flowing,
because
almost
everything
is
ins
you
registered
into
you
didn't
register
long.
You
don't
see
that
you're
missing
something
it
takes
a.
B
Okay
yeah,
I
I
see
that
I
mean.
B
B
A
Yeah,
it's
either
either
the
enable
measurement.
You
know
that
throwing
of
hey
you
don't
have
a
handler
for
this
type.
That
would
actually
be
one
way
to
do
it,
which
means
you
have
to
call
set
measurement
first
or
set
measurement
event.
Callback
first.
That
would
actually
be
very
in
your
face
of
hey.
You
don't
have
a
handler
for
this
kind
of
instrument,
but
if
you're
allowing
them
to
be
set
or
called
in
arbitrary
orders,
it's
do
you
want
a
another.
A
B
A
I
really
might
yeah
so
while
I'm
asking
do
we
need
to
add
api
for
it.
It's
what's.
What's
the
user
experience
around
the
mismatch
and
if
the?
If
the
answer
is
you
have
to
call
set
measurement
event,
callback
first,
then
enable
measurement
events
can
throw.
You
get
a
very
detailed
exception
message
now.
You
know
what
to
go
fix,
but
it's
if
you
called
enable
on
a
thing.
That's
int
and
you
didn't
have
an
end
handler.
Then
you've
lost
data,
but
nothing
told
you.
A
B
H
B
B
Right
and
also
I
expect,
like
you,
know
the
listener,
widely
initialized
the
listener
in
the
beginning.
They
just
sit
this
callbacks
and
they
forget
about
like.
H
H
Yeah,
I
guess
I'm
getting
at-
we
don't
expect
the
user
to
have
to
create
their
own
dictionary
anyway,
with
the
typical
usage
of
this.
B
No,
I
mean
like
I
expect
yeah.
I
know
that
you
missed
the
first
part,
but
usually
I
mean,
like
you
know,
in
open
telemetry.
They
are
going
to
have
the
sdk
which
is
implemented
like
you
know,
aggregating
the
the
whole
measurement
transistor
and
they
will
listen
to
almost
like
any
any
instruments
they
need
and
they
will
aggregate
like
the
data
from
every
every
instrument.
J
So
so
I
think
I'm
I'm
trying
to
implement
the
sdk
version
of
it,
and
I
think
too,
the
answer
to
your
question
is
that
I
don't
want
to
keep
a
dictionary
of
the
instrument,
and
thus
I
use
the
state
that
is
then
set
and
passed
back
to
me.
H
A
So
off
the
top
of
my
head,
I
see
four
options
for
the
scenario
so
just
to
get
some
thoughts
flowing
one.
Is
we
don't
care
caller?
Beware
if
you
don't
handle
a
thing.
It
goes
in.
The
garbage
number
two
is
that
your
design
is,
you
have
to
call
set
measurement
event
callback
before
you
call
enable
measurement
events
and
if
you
call
enable
measurement
events
and
the
t
is
not
one
that
you've
already
handled,
you
get
an
exception,
which
is
you
weren't
going
to
handle
this
you're
not
doing
the
api
right.
A
Number
three
is
a
callback
with
the
instrument
of
I
had
data
for
this,
but
you
didn't
have
a
handler
and
number
four.
Is
we
remove
the
generic
constraint
off
the
measurement
callback
and
you
make
a
default
measurement
event?
Callback
which
takes
a
box
to
t
so
t
becomes
object
and
then
that
lets
you
get
the
fine.
You
can
register
the
one
handler
and
if
you
really,
if
you're
just
going
to
call
tostring,
then
you
can
just
take
the
box
and
deal
with
it.
A
B
A
B
Exception,
if
they
we
have
the
option
to
just
ignore
it,
not
doing
anything
sort
of
yeah.
I
mean
like
in
the
in
the
tracing
in
general.
I
got
like
you
know.
We
are
trying
to
avoid
strong
exceptions.
I
mean
like,
like
handling
exceptions.
I
mean
in
the
middle
of
stuff
like
this.
It
will
be
yeah.
I
mean
like
with
no
exception
only
I
mean
like
while
you
create
instrument
not
passing
like
name
or
something
like
this
yeah.
A
Right,
so
I
wouldn't
throw
an
exception
when
you
get
to
the
point
where
you
want
to
call
the
callback
and
it's
null,
but
during
the
time
that
they're,
basically
building
up
the
listener
of
hey.
I
want
to
turn
on
this
instrument,
throwing
the
exception
of,
but
you
can't
handle
it
seems
reasonable
to
me
and
if
they
want
to
say,
ignore
anything
I
can't
handle
then
they'll
just
catch
that
exception
and
ignore
it.
H
A
Yeah
and
like
if,
if
you
think
that
the
best
answer
is
that
somebody
who
gets
in
the
state
deserves
the
pain
that
they're
going
to
suffer
from
being
in
that
state,
then
that's
fine.
It
just
feels
like
we're
taking
a
thing,
that's
hard
to
use
and
we're
making
it
harder
to
use
by
not
giving
you
the
feedback.
B
I
don't
have
a
specific
scenario,
but
what
I
can
see
like
you
know
somebody
create
a
listener
and
hawaii
you
start
as
a
listener.
You
will
get
a
bunch
of
instruments
you
can
just
like
select,
which
one
maybe
you
can
interested
and
at
some
point
later
I
mean,
can
decide
what
oh
okay.
So
it's
time
now
to
listen,
I
mean.
A
Okay
feels,
like
you
just
want
to
boolean
in
your
callback
then,
but
or
that
you
have
state
that
you're
tracking
in
the
callback
of
are
you
actually
listening
or
not
like
you
can
solve
that
because
you
have
the
state
and
you
control
the
thing
that
gets
called
back
into.
You
can
have
your
own.
Do
I
care
or
not,.
B
Okay,
the
other
question
about
like
what
you
are
saying,
is
and
set
measurement
event
callback.
If
somebody
at
some
point
want
to
disable,
I
mean
like
listening
to
to
some
measurement
from
any
instrument,
so
we
had
the
option
I
mean
just
like
today,
I
mean
like
in
our
thoughts
about
like.
Maybe
you
can
set
it
back
to
now,
and
it
will
return
to
the
fault.
So
you
will
not
have
any
callback
for
this
time.
B
That
yeah
victor,
do
you
think
in
any
scenario
that
could
need
that.
J
So
before
I
answer
that,
I
I
think
maybe
a
little
bit
of
a
history
of
why
we
currently
have
the
set
measurement
event,
callback
of
t
and
I
think,
the
primary
reason
or
concern
that
we're
concerned
about
is
performance
in
terms
of
having
to
box
a
t
to
pass
into
it.
If
we
were
able
to
avoid
that
problem-
or
you
know,
find
a
different
way
to
that
solution,
then
we
likely
would
not
have
a
you
know
registered
callback
per
type.
J
Rather,
you
know
we'll
just
have
a
you
know,
callback
with
just
your
measurement
and
then
leave
it
to
the
sdk
to
determine
what
to
do
with
that
type
t.
So
so
that
that
that's
the
for
me,
that's!
The
initial
question
is:
is
it
common
to
register
a
callback
with
a
type
t
for
performance
reason,
or
should
we
just
take
a
box
version
of
it,
and
this
is
purely
from
performance
perspective.
G
Yes,
we
did
so
the
like
at
worst
case,
you
would
have
that
number
squared
in
terms
of
a
bunch
of
different
conversion
functions
in
as
an
internal
implementation
detail.
So
there's
nothing,
at
least
in
my
mind,
inherently
wrong
with
just
maintaining
that
internally,
avoiding
the
box
and
then
handing
the
correct
value
back
off
to
people.
That's.
A
Fine
for
a
thing
that
we
can
enable
to
do
performance
like
the
the
suggestion
I
had
of,
if
we
remove
the
constraint
off
of
measurement
callback,
and
then
we
have
either
a
property
for
the
the
single
handler
or
a
method
or
whatever
for
a
default
measurement
event.
Callback
that
takes
the
boxed
value,
then
that
a
lets
people
who
don't
care
about
the
performance
overhead
of
boxing
write
simpler
code
and
use
the
api
and
b
give
someone
who
did
care
about
performance.
A
A
A
Like
these
are
really
the
the
top
two
ways
that
to
me
feel
like
they
solve
the
scenario.
One
is
you
let
somebody
say
give
me
the
box
thing
if
I
didn't
have
a
better
handler
for
it,
and
the
other
is
just
a
callback
for
tell
me
if,
if
you
were
trying
to
give
me
data
for
this
instrument,
but
I
didn't
have
a
callback,
I
think
this
one's
actually
more
versatile.
A
So,
somewhere
inside
your
code,
you
have
that
you
know
record
observable
instruments
was
called
and
you
see
you
have
this
instrument
of
long
and
you're
going
to
look
up.
Did
they
have
a
callback
for
long
right
now,
you're
going
to
do
nothing
if
they
didn't
and
instead
you'll
cast
or
you'll
box
the
long
into
an
object
and
call
their
default
measurement
callback
if
they
have
one
so
they
have
the
escape
valve
for
any
type
from
the
future
they
already
handle.
A
But
it's
not
a
perf
issue.
It's
a
well!
I
mean
it's
a
perf
issue
for
people
who
think
it's
a
perf
issue,
but
if
they
think
it's
a
perf
issue,
they
probably
shouldn't
be
using.net
like
we.
We
particle
all
over
the
place.
The
having
the
valve
to
let
someone
opt
in
to
not
have
to
deal
with
a
box.
Stint
is
fine,
but
like
boxing
is
not
the
end
of
the
world.net
applications
and
services
have
existed
for
15
years
without
us
doing
things
like
this.
A
So
I
think
that
the
t
is
a
is
a
fine
thing,
but
our
usual
stance
for
performance
is
let
someone
opt
into
the
more
complicated
pattern
if
they
want
it
for
performance,
but
make
the
make
the
simple
scenario
just
work,
and
if
we
allow
them
to
get
a
measurement
callback
of
object.
That
makes
it
just
work.
B
Just
to
clarify
what,
like
you
know,
perf
is
one
of
the
goals
of
the
metrics
apis
in
general.
If
we
didn't
get,
the
perf
could
right,
so
this
apis
will
not
be
used
right,
and
so
so
second
thing
is,
like
you
know
what
you
are
proposing
here
is,
like
you
know,
boxing
yeah,
I
mean,
like
you
say,
like
yeah,
I
mean
that's
what
I
mean
for
even
I.
A
B
G
E
G
G
What
I'm
trying
to
figure
out
is
if
we
do
give
people
like
a
generic
here's,
a
value
api.
That's
something
that's
supposed
to
be
easy.
I
don't
think
object.
Is
the
right
exchange
type
for
that?
Maybe
I
convertible,
but
but
you
know
I
I
want
to.
I
want
to
rinse
my
mouth
out
with
soap
right
now
for
saying
that,
but
just
something
that
has
easy
apis
hanging
off
it
kind
of
like
json
value.
For
instance,
it's
like
hey
here's,
an
arbitrary
thing.
I
need
an
integer.
I
need
a
double.
G
G
D
B
E
G
D
B
G
That's
right,
let's
just
make
sure
we
have
good
samples,
at
least
for
this,
because
I
I
have
seen
so
many
times
people
get
burned
by
not
being
able
to
unbox
something
properly.
A
G
A
A
Well,
yeah,
you've,
if
it's
a
observable
instrument,
you've
now
lost
the
data
like
it's
gone.
If
it's
actually,
if
it's
a
streamy
one
you've
lost
it
too,
because
you
can't
test
them
for
their.
So
really.
This
is
just
letting
you
see,
here's
the
name
and
you
can
try
figuring
out
what
the
t
that
should
have
been
associated
with
it
was,
but
there's
a
thing
that
you
enabled
that
you
weren't
actually
listening
to
I'm
telling
you
about
it.
A
Yes,
but
then
that
would
just
be
the
name
versus
the
instrument.
You
can
look
at
the
instrument
of
like
you're
looking
at
the
docs,
and
it
says
it
should
be
an
int,
but
at
runtime
you
look
and
it
says
it's
a
long
and
you're
like
well.
That's
why
my
handler
didn't
handle
it.
So
I
think
the
instrument
is,
it
is
the
exchange
type
for
this
type,
so.
B
Right
also,
I
want
to
mention
about
like
there
is
a
discussion
in
the
future.
They
will
add
some
things
called
the
hinting
to
the
instruments
and
hunting
will
add.
Some
more
information
telling,
like
you
know,
can
tell
about
some
more
about,
like
maybe
part
of
the
hint
is
like
telling
yeah,
I'm
I'm
interior
I'm
longer,
sometimes.
G
I
Yes,
from
the
api
part
we're
going
to
need
to
tweak
that
we'll
receive
the
exact
type
that
the
user
passed
in
and
from
the
actual
implementation
of
the
consumer
of
these
listeners.
We
will
be
able
to
give
the
default
behavior
and
also
allow
people
to
do
configurations,
so
they
can
lose
precision
if
they
want.
I
A
Okay,
so
I
doodled
a
thing:
does
anybody
have
opinions
on
the
name
for
what
to
do
when
there's
a
measurement
that
reports
that
an
instrument
that
reports,
a
measurement
that
you
don't
have
a
handler
for
unhandled
instrument,
unhandled
measurement
and
halogen
instrument
reported,
will.
A
I
A
I
A
Yeah
I
mean
to
me
the
real
concern
is
that
you,
you
wrote
a
consumer
of
this
and
you
registered
every
numeric
type
that
the
docs
say
or
supported,
and
you
think
you're
good
to
go,
and
then
you
find
in.net
seven
that
because
you're
just
in
the
middle
and
you're
letting
other
people
enroll
in
things,
and
then
you
find
out
in
dot
net
seven
that,
like
oh,
we
also
added
all
the
other
sign
variants
of
the
numeric
types
and
now
you're
missing
half
the
handlers.
Nothing
is
going
to
have
told
you
that
that
that
was
true.
A
D
So
the
one
thing
that
derek
alluded
to,
but
he
didn't
give
too
many
details-
is
hinting
that's
an
api.
We
are
planning
to
work
on
the
future
where
the
producer
of
a
metric
could
you
know,
give
a
hint
to
the
consumer
that
this
is
the
recommended
configuration
and
how
you
consume
this.
I
I
would
hate
to
have
like
this.
You
know
like
third
of
an
api
left
if
we
have
a
better
hinting
thing
in
future.
D
G
B
A
A
I
A
Alrighty
so,
according
to
my
calendar,
we
are
meeting
again
at
10
a.m.
On
thursday
redmond
time
to
help
burn
down
some
of
this
red.
A
Right,
yes
and
that'll.
G
A
A
that'll
be
a
two-hour
meeting
and
based
on
where
we
are
in
the
release
cycle
and
things
emo's
looking
for
time
to
maybe
increase
what
we're
doing
in
a
week
even
more,
because
apparently
we
all
just
like
being
in
meetings.
E
What
can
I
say
every
time
we
try?
Email
like
it
seems
like
you.
B
Design
review
in
general,
but,
like
you
know
because,
like
we
are
limited
to
july
17th
for
all
to
have
like
all
public
api's
alex
and
I'm
not
sure
about
like
you
know
if
this
is
going
to
skill,
because,
like
I'm
expecting
like
in
next
two
reviews,
we
will
get
like
a
lot
of
ebi
proposals.
I
think
to
to
have
the
people
catch
up.
I
mean
before
freezing
so
I'm.
E
It
scales
or
not,
I
don't
think,
even
matters,
because
I
don't
see
what
alternative
would
be.
I
mean
we
will
try
to
look
as
much
as
we
can
and
then
we
try
to
give
like
get
it
get
as
much
as
approved
as
we
can,
and
if
we
have
to
ship
something
in
preview
without
looking
at
it.
First
then,
that's
unfortunate,
but
eventually
we
have
to
look
at
every
single
thing.
We're
shipping
right.
A
E
A
Rambling
internet
so
see
you,
thursday,
10
a.m,
redmond
time
for
yet
more
as
the
api
turns.