►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello
friends,
we
are
live
again
today
we
will
focus
on
a
few
things
that
are
blocking
our
progress
for
n5.
We
start
with
the
console
logger
that
we
have
reviewed
in
the
past
miriam.
Do
you
want
to
talk
about
this.
B
Yes
sure
one
moment
so
basically
with
the
cons,
so
this
bug
kind
of
existed
before
we
added
console
formatting,
but
it
only
existed
for
nc,
sorry
for
yeah
ansi
supported
os
like
linux
or,
I
believe,
osx.
So
then.
The
reason
it
was
happening
is
that
at
the
end,
while
we're
trying
to
print
logs
to
the
console,
we're
kind
of.
B
Trying
to
think
anyways,
it
doesn't
matter
the
implementation
detail,
but
where
we
are
now,
we
basically
want
to
make
sure
we
want
to
make
sure
that
if
console
is
redirected
and
if
the
console
is
redirected
and
the
it's
on
a
system
that
doesn't
support
ansi,
we're
gonna
get
these
color
code
numbers
because,
okay,
let
me
start
over
basically,
so
we
wanna
make
sure
we
don't
spit
out
these
codes
where
we
don't
want.
Where?
A
Yeah,
so
with
the
way
I
saw
it
like
I
mean.
Basically,
the
problem
is
now
that
we
use
sort
of
calling
the
console
color
apis.
We
are
basically
emitting
the
nc
escape
sequence
directly
into
the
log
right,
because
we
say
we
don't
want
to
model
colorization
as
a
logging
concern
and
now
the
problem
is
that
in
the
kubernetes
case,
where
they
effectively
host
asp.net
and
redirect
the
output,
we
see
all
the
colors
right
or
the
the
the
color
codes
right.
So
I.
B
Guess,
rice
yeah,
the
problem
could
arise
when
the
I
believe
only
when
the
console
effectively
at
the
end
doesn't
support
nc
codes,
it's
just
going
to
spit
them
out.
A
C
B
B
Yeah
exactly
and
then
then
the
question,
and
then
there
was
a
question
that
what
if
the
console
is
redirected
but
color
is
nc,
color
formatting
is
available.
Right
then.
B
Because
of
that,
we
kind
of
if
you
scroll
down
to
the
apis,
we
thought
that
maybe
it
would
be
good
to
provide
a
choice
that
we
don't
necessarily
disable
these
emitting
these
color
codes
anytime.
We
have
console
redirected,
we
only
if,
if
like
we
have
so
so
we
kind
of
have
control
over
whether
or
not
we
want.
A
So
the
thing
I'm
struggling
with
is
that
so
that
normal
wisdom
says
basically,
when
you
redirect
output,
you
don't
want
nc
escapes.
On
the
other
hand,
though,
when
you,
when
you
pipe
to
let's,
say
something
like
a
pager
like
less,
you
still
want
color
so
like
to
me.
It
seems,
like
redirection
by
itself,
wouldn't
be
sufficient
to
say
disabled
colorization
right.
So
I
don't
know
how
linux
does
it
do
they.
I
mean
I
thought
that
normally
the
normal
way
they
do
it
is
they.
A
They
basically
ask
basically
what
the
terminals
capabilities
are,
which,
in
the
case
of
redirection,
would
be
different
from
when
you're
not
redirected
by
default.
I
guess
when
you
read
it
back
to
a
file,
it
would
be
different
from
redirecting
to
another
process.
Like
that's
the
thing,
I'm
I'm
I'm
not
sure.
So
it's
the
expectation
here
that
we
just
don't
make
the
determination.
We
just
give
people
an
enum
and
they
can
say
well,
you
can
you
can
decide
if
you
want
to
disable
color
as
soon
as
you're,
redirected
or
use
it's.
You
know.
B
When
you
say
always
on
always
off,
is
it
well
because
it's
an
option,
it
could
be
changed
within
the
time
of
the
application,
but,
like
I
think
what
yours
your
the
sample
you.
The
use
case
you
gave
is
that
you
have
one
application,
but
it
might
go
to
file
and
then
also
might
go
to
a
different
process.
And
then
maybe
one
process
allows
coloring
and
then,
for
that.
A
Yeah
my
current
example
would
be
like
git
log
right
when
you
invoke
git
lock
it
basically
spools
the
you
know
the
the
the
the
the
commit
history
on
your
con
on
your
console
and
you
can
and
it
kind
of
colorizes
that
right,
but
by
default
it
will
also
pipe
itself
to
less
and
then
then
the
idea
is
well.
If
it's,
if
it's
pipe
to
less
and
you
scroll
up
or
scroll
down,
you
still
want
to
see
colors
right.
But
if
you,
let's.
C
A
Pipe
it
to
a
file
and
you
open
the
file
in
notepad.
You
don't
want
to
see
you
know
the
nc
code
so
like
I
don't
quite
understand
how
linux
handles
that,
because
clearly
they
they
must
know
whether
you
redirect
to
a
file
or
whether
you
redirect
to
a
process
right.
Somehow
that-
and
I
guess
in
the
kubernetes
case-
I'm
not
entirely
sure
about
it.
But
I
would
be
fairly
confident
that
it's
probably
directed
to
a
file
right.
A
B
A
A
D
D
D
Is
to
be
able
to
give
us
an
indication
of
whether
they
didn't
they
didn't
change
it,
so
we
should
make
some
sort
of
you
know
heuristic
like
like.
Should
we
check
if
the
output
is
redirected
or
there
was
another
in
a
linked
issue?
There
was
also
like
this
no
color
environment,
variable
that
some
things
respect,
and
so
the
idea
is
we
could
make
heuristics
about
what
we
should
do
by
default.
A
D
A
Yeah,
I
guess
my
question
is
like
a
little
slightly
more
broad.
It's
it's
like.
What's
the
correct
behavior
that
linux
apps
are
doing
and
like
for
them,
I
heard
from
last
time:
was
there
really
isn't
the
you
know?
The
one
smart
way
of
doing
things
and
nc
escapes
are
a
pain
in
the
unix
environment
as
well,
but
should
this
be
basically,
does
this
belong
to
logging,
or
should
this
be
a
general
concern
because
it
seems
like
other
kinds
of
apps
would
have
the
same
issue
right?
A
D
B
A
D
Like
the
boolean,
the
boolean
disable
colors,
I
think,
isn't
flexible
enough
for
us
to
be
able
to
tell
if
somebody
just
wants
the
default
behavior
or
if
they
always
want
it
on,
I
mean
having
it
always
off.
You
can
tell
because
they
would
have
to
change
it
from
the
default.
So
we
can't
tell
we
can't
tell
if
they
explicitly
wanted
luck,
coloring
enabled
or
if
they
just
said
whatever
the
default
is.
A
Yeah,
I'm
not
having
a
problem
with
that
per
se,
like
I
guess
I'm
trying
to
just
assess
like
if
we
were
to
fix
underlying
issue.
Would
we
regret
having
that
api
here,
but
I
guess
what
you're
saying
is.
Even
if
we
have
a
property
on
console
that
says
like
something
like
to
the
extent
of
x
should
you
use
colors,
then
we
would
just
say
that
when
you
say
default
here
we
would
just
honor
whatever
that
setting
is
right.
D
D
D
A
Yeah,
I
guess
my
question
would
be:
let's
say
we
would
have
this
enum,
but
we
would
basically
so
instead
of
putting
it
on
the
logger
options,
you
would
literally
put
it
on
console
and
we
would
just
say
everybody.
Whoever
does
colorization
should
honor
that
enum.
A
Basically
like
having
the
having
the
color
behavior
literally
on
console
as
a
settable
property
like
color,
console
behavior
right
and
then
we
would
just
say
everybody.
Whoever
does
any
sort
of
colorization
whether
they
call
you
know
the
normal
console
api
so
that
they
literally
use
the
you
know
the
the
nc
escapes
directly
like.
Should
you
or
should
you
not
like
use
colors,
if
you
literally
produce
an
output
that
goes
to
the
terminal.
A
D
A
A
A
E
B
B
Yeah,
what
if
what?
If
the
we
didn't
add
this
api,
like
we
had
disabled
colors
as
the
boolean
and
then
because
sorry,
because
we
we
we
kind
of
disable
already
by
default
when
output
is
redirected.
But
then,
as
part
of
later,
when
we're
trying
to
fix
the
three
nine
like
the
other
issue,
then
we
kind
of
maybe
have
some
apis
on
system
console
that
already
solve
might
be
able
to
solve
what
to
do
when
an
output
is
redirected
so,
like
we
won't
change
any
apis
now.
B
E
B
No,
the
reason
for
having
the
disabled
disabled
colors
here
is
that
even
for
systems
that
do
allow
having
colors,
you
might
sometimes
want
to
toggle
and
say,
don't
display
them
so
that
that
would
have
been
the
reason
for
having
the
property
disable
colors.
Even
but
then.
D
B
Yeah,
what
I'm
trying
to
say
so
like,
even
if
we
have
the
setting
on
system
console
that
would
do
the
disabling
and
or
not
here
we
have
this
off.
We
would
have
this
logging
options
to
to
just
sometimes
disable
the
color
for
all
the
logs,
but
I
I
see
and
now
that
I
now
that
I
said
this-
I
see
why
I
I
haven't.
E
Yeah,
I
think
a
good
example
is
ms
build
it.
It
has
the
ability
to
write
to
a
file
and
simultaneously
print
to
the
console.
The
console
output
is
typically
colored,
while
the
file
output
doesn't
contain
ascii
escape
characters
and
if
they
ever
switched
to
using
ascii
escape
characters.
I
imagine
they'd
want
to
maintain
that
where
console
has
colors
and
the
file
output
doesn't
but
they're
still
writing
the
same
text
to
both
places.
B
What
I
could
imagine
like
with
my
microsoft
extension
logging,
because
when
you
create,
when
you're
setting
up
logging
when
you're
setting
up
logging,
you
can
have
different
providers,
one
for
console,
one
for
event,
source
blogger
or
like
writing
to
file
or
everything,
and
each
of
them
could
have
their
own
logic.
B
Of
how
it's
done
and
like
for
now
console
would
have
this
kind
of
logic
that,
like
the
ansi
parser
exists,
and
all
of
that,
maybe
what
I'm
trying
to
get
at
is
that,
like
maybe
in
the
case
of
the
sample
that
you
mentioned
tanner
like
the.
B
If
you're
writing
to
output,
you
like
we
don't.
I
mean.
B
And
also
in
the
same
example
that
emo
provided
where,
like
git,
when
you
do
git
log,
you
fall
right
to
file,
you
don't
see
the
escape
codes
and
then,
when
you're,
some
on
the
console,
you
see
the
colors.
Maybe
that
could
be.
Why?
Because
the
logic
there's
different
providers
and
each
provider
has
their
own
logic
for
printing
locks.
A
Yeah,
I
guess
my
only
statement
would
be.
I
think,
there's
a
two
tenants
point.
I
think
every
every
data
sync
right
that
basically
either
prints
to
the
console
or
prints
or
some
other
arbitrary
thing
that
you
connect,
like
you
know
a
database
or
a
file
or
whatever
that
doesn't
necessarily
go
through
console
redirection
will
basically
have
to
have
its
own
setting
right
or
its
own
smart
detection
right.
So
if
you
have
a
provider
model
that
is
polymorphic
and
you
have.
C
A
Use
a
system-wide
provided
setting
right
because
it
seems
like
for
terminal.
I
think
you
want
a
uniform
behavior
like
I
really
have
a
hard
time
seeing
a
world
where
I
want
one
behavior
for
logging,
but
a
different
implementation
for
my
own
outputs.
That
seems
weird,
because
if
I
redirect
the
entire
console,
then
I
probably
want
the
same
behavior
for
everything
right.
B
A
A
B
A
I
think
that's
the
that's
actually,
the
I
always
thought
of
the
console
called
apis
as
being
shitty,
but
that's
one
thing
that
actually
solves
quite
nicely:
it
doesn't
require
participation
for
everybody
who
produces
log
messages
or
output
messages.
A
D
A
B
A
Only
concern
really
is
is
that
we
basically
end
up
in
the
world
where
this
kind
of
pattern
is
now
everybody
has
to
repeat
this.
That's
the
thing
I
really
would
like
to
avoid.
I
mean
it's
okay
to
have
some
duplication
in
terms
of
api
surface,
but
I
think
in
the
long
run
we
should
have
a
world
where
people
can
just
safely
call
console.writeline,
and
the
right
thing
will
happen
like.
I
don't
think
that
everybody
should
do
crazy
gymnastics
to
figure
out
or
should
I
should
I,
you
know,
emit
colors,
or
should
I
not
emit
colors?
D
A
A
Mean
on
console,
like
I
think,
yeah,
I
think
the
big
feature
there
would
be
if
you
do
something
smart,
like
filtering
text
that
you
put
you
put
the
console.writeline
right,
that's
not
what
I'm
proposing
when
I'm
proposing
it's
just.
You
know,
instead
of
having
this
query
api
that
you
can
override
on
on
this
on
the
simple
logger
you
just
have
it
there,
the
only
problem
of
that
is,
then
you
know
you
wouldn't
be
able
to
configure
it
in
the
config
system
right
and
I
buy
that
that's
unfortunate.
A
C
Would
we
ever
change
default
here
to
have
a
different
default?
So
so
right
now,
as
proposed
here
default,
is
look
at
whether
output
is
redirected
right.
Would
we
ever
in
the
future,
change
this
change
default
to
say?
Oh,
don't
look
at
whether
something's
redirected
anymore
go
look
at
this
other
thing
instead,
such
as
what
system.console
is
actually
doing,
once.net
60
comes
around.
D
C
Could
change
over
time
so
that
then,
that
also
tells
me
that
default
is
a
good
name,
because
we're
we're
able
to
change
the
behavior
to
match
people's
general
expectations.
A
D
A
A
Well,
yeah,
even
for
regular
ones,
very
often
you
could
get
away
with
having
none
as
a
sensible
value,
but
like
for
for
this
thing
I
mean
default,
also
makes
sense
to
me
and
it's
it's
literally
the
default
value
too.
So
it's
fine.
D
A
C
Okay,
yeah
yeah,
you
had
suggested
auto
as
well.
I
think
either
of
those
it's
just
fine.
Do
we
have
a
preference.
A
A
B
May
I
ask
if
we,
if
system
console,
had
the
mechanism
for
us
to
choose,
if,
if
system
console,
had
the
mechanism
for
us
to
choose
to
like
disable
or
not
based
on
output
being
redirected
or
not,
we
didn't
need
this
enum
right,
we
would
have
just
been.
B
It
would
have
been
still
enough
to
just
use
the
boolean,
but
then
the
argument
was
that
what
if
we
have,
let's
say
a
file
logging
or
like
other
types
of
logging,
then
is
it
going
to
be
enough
to
have
like
the
disabled
colors
on
top
of
the
console?
Formatter?
D
B
So
you're
saying,
if,
if
we
toggled
between
true
or
false
for
in
the
config,
to
enable
or
disable,
even
if
we
had
the
apis
in
system
console,
we
wouldn't
be
able
to
toggle
if
a
console
is
redirected
or
not.
D
B
D
So
today,
system.console
doesn't
write
colors
if
the
output
is
redirected.
If
we
had
an
api
in
system.console
that
let
us
override
that,
let
the
you
let
the
developer
override.
No,
even
though
it's
redirected,
I
still
want
you
to
write
colors
the
end,
the
end
person
who's
running
the
app
wouldn't
be
able
to
in
their
configuration
file
set.
B
B
I'm
not
sure,
I'm
not
sure
I
follow.
B
B
Yeah
in
the
future
yeah,
so
that's
what
I'm
saying
I'm
saying:
if
that's
the
only
reason
for
adding
this
enum,
then
maybe
we
could
wait
until
you
decided
what
what's
gonna
happen
for
system
console,
but
I
mean
I
don't
have
a
strong
opinion.
If
you,
if
you
think
that
what
we
already
have
is
not
enough,
then
we
can
just
use
the
enum.
B
Well,
I
don't
know
exactly
what's
going
to
be
in
system
console,
so
if,
if
we
were
able
to
change
the
behavior
on
system
console
to
allow
colors.
A
Yeah,
I
think
the
idea
would
be
that
we
would
say,
and
we
would
give
some
setting
on
console
that
would
logically
be
very
similar
to
this
enum.
We
would
say
by
default,
we
detect
something
right:
either
it's
an
environment
variable
or
some
things
like
the
the
output
is
redirected
to
determine
whether
color
should
be
emitted
or
not.
And
then
we
surface
this
setting
up.
So
people
who
construct
strings
can
use
that
setting
to
determine
whether
they
should
invoke
whether
they
should
include
ncscapes
or
not,
and
the
second.
C
A
A
That
would
be,
I
guess,
the
the
feature
that
console
has,
but
I
think,
even
if
you
had
that
now
the
question
is:
if
I
want
to
configure
my
my
logging
via
the
you
know,
microsoft
extensions
configuration
system,
I
might
still
want
to
dictate
what
I
want
the
system
to
be
doing,
regardless
of
what
console
decided
right.
So
in
that
sense,
I
think
the
enum
would
probably
still
make
sense.
B
A
But
yeah
I
don't
know
what
else
to
do.
I
mean
yeah
as
eric
said
right.
The
problem
is,
you
know
I
don't
like
shipping
instant
legacy,
but
there's
also
this
volume
of
like
you
know,
we
need
to
lock
down
the
release,
and
so
we
have
limited
run
member
what
we
can
do
for
console,
but
I'm
not
entirely
sad
that
we
would
have
this
api
in
two
places
then,
because
it
seems
still
available
in
in
the
logging
system
to
just
override
it.
C
A
But
I
think
the
boolean
wouldn't
be
enough,
because
if
you,
if
you
only
have
a
boolean,
you
have
the
same
problem
that
we
have
today
right,
which
is
you
can
either
turn
it
on
or
off.
But
then
that
means
the
person
who
configures.
This
has
to
know
what
the
correct
thing
is,
which
you
might
not
right,
because
the
person
that
wrote
the
app
and
the
person
that
deploys
in
kubernetes
might
be
to
two
different
people.
And
then
you
have
to
change
your
code
or
something
to
actually
disable
the
output.
A
A
A
D
Yeah
suppose
he
says,
I'm
not
sure
why
it
does
not
default
to
true
when
console
output
is
redirected,
is
true,
and
so,
like
that's
kind
of
that's
kind,
of
the
exact
reason
why
splitting
this
bool
into
an
enum.
So
we
can
tell
if
somebody
explicitly
explicitly
says
enable
colors
or
what
the
default
behavior
is.
A
D
C
A
Yeah
I'm
I
agree
like
that
seems
wacky
all
right,
then,
let's
just
improve.
We.
A
D
D
A
So
yesterday
we
we
reviewed
part
of
the
proposal,
which
was
the
I
think
we
reviewed
the
windows
only
setting
and
we
reviewed
the
something
else
I
forgot,
but
so
basically
the
proposal
here
is
so
we
have.
A
These
guard
calls
now
right
which
basically,
we
decided
to
put
on
runtime
information
and
the
problem
with
those
is
that
they
are
on
one-time
information
which
already
shipped
in,
I
think
2-0,
I
believe,
or
even
one
one
and
we
put
it
in
interweb
services
because
well
you
check
for
the
os,
because
you're
likely
going
to
be
invoke
right,
and
that
makes
sense,
but
back
back
then,
but
now
with
the
new
design.
A
The
expectation
is
that
customers
who
just
use
os
bindings
like,
for
example
or
pretty
registry
types
or
you
know
echo
apis
or
ios
and
android
bindings
they're,
not
really
p,
invoking
themselves
right.
They
don't
really
deal
with
interrupt
themselves.
They
just
use
a
thing
that
may
internally
use
that,
but
all
they
want
to
know
is.
Can
I
call
this
api
safely?
Like?
Is
this
api
actually
supported?
A
The
key
thing
here
is,
I
believe
that
we
basically
say:
okay,
the
person
wants
to
do
a
simple
task.
They
should
find
the
type
and
it
should
not
involve
like
crazy,
usings,
right
and
so
environment
seems
like
the
best
fit,
because
that's
where
os
version
is
today,
os
version
is
relatively
fairly
popular
still
on
based
on
telemetry
that
we
have
runtime.
Information
is
not,
but
it's
also
fairly
recent
right,
I
mean
not
in
a
chorus.
You
know
we
think
of
it
as
ancient
history.
A
At
this
point,
but
like
it's
still
fairly,
you
know
only
if
you're
a
few
years
old
versus
dotted
framework
is
20
years
old.
So
that's
why
my
proposal
is,
we
move
them
to
environment
and
then
we
basically
don't
tell
people
to
use
the
runtime
information
type
unless
they
actually
want
to
do
some
things
that
we
don't
support
and
there
really
isn't
much
left
because
you
know
with
this
one
they
could
do
everything
now,
there's
some
console.
I
basically
when
I
moved
them.
A
I
also
simplified
the
call
because
it
seemed
like
we
went
for
you
know.
Originally.
We
only
had
those
guys
here
the
strongly
tight
ones,
but
then
we
basically
decided
that
we
put
strings
and
attributes.
Then
we
said:
okay,
we
should
probably
also
have
a
string
based
overload
on
those
and
then
my
reasoning
was
well.
A
Parsing,
isn't
you
know
super
expensive,
but
it's
also
not
super
cheap.
If
you're
on
a
hot
path,
and
so
the
idea
over
there
was
well,
maybe
we
should
have
those
still
now,
I'm
not
entirely
sure
that
even
having
those
is
sufficient
for
the
hot
path
either
I
try
to
get
an
answer
out
of
yon,
but
he
basically
just
said
like
well
it's
better
than
what
we
have
otherwise.
So
I
guess
that's
fair
booyah
pointed
out
that
we
have
some
amount
of
like
caching
that
we
can
support
analyzer
thanks
to
data
flow.
A
But
if
you
extract
this
to
a
field,
then
at
that
point
we
are
lost.
There
really
isn't
a
reason
why
we
couldn't
support
the
analyzer.
It
just
gets
more
complicated,
but
we
could
probably
build
somewhat
straightforward
heuristics
like
if
the
field
is
read
only
and
you
initialize
it
in
the
constructor.
Well,
then,
we
can
probably
look
this
up
right,
but
I
don't
think
we
would
ever
do
like
cross
method
flow
analysis
right.
So
we
would.
A
We
would
have
to
be
able
to
like
determine
effectively
what
this
thing
is,
and
maybe
we
can,
but
I
guess,
for
hot
loops
there
will
probably
still
work,
but
if
you
have
a
hot
path
that
involves
several
methods,
then
maybe
the
local
variable
also
won't
help
you.
So
I
don't
actually
care
that
much
because
they're
all
overloads
and
we
usually
don't
think
of
overloads
as
increasing
the
concept
count,
so
I'm
fine
with
taking
them
all
as
is
and
moving
them
to
environment.
A
That
seems
fine
to
me
and
then,
if
we
really
really
wanted
to,
we
could
also
move
this
guy
here,
but
that
seems
excessive,
because
the
only
reason
we
support
this
guy
today
is
because
of
existing
code.
C
Can
can
you
bring
that
issue
up
on
the
on
the
main
screen.
A
D
D
A
A
A
Well,
I'm
selecting
on
the
screen
like
I'm,
assuming
that
you
can
see
my
selection
but
like
so
basically
the
the
os
platform
all
later
apis
that
exist
on
runtime
information.
They
don't
exist
yet
they
haven't
shipped
yet
so
we
can
completely
nuke
them
from
runtime
information
and
physically
transparent
them
to
environment.
A
The
isos
platform
call
already
exists
and
has
shipped
whereas
platform
already
exists
and
has
shipped
so
we
can't
fundamentally
move
os
platform
from
interop
services
to
system
right.
So
the
best
we
could
do
is
you
could
say
like
yep,
that's
what
you
used
to
do
in
the
past
and
you
know
that's
it,
but
like
new
people
who
just
want
to
on
ios
check
whether
something
works
don't
have
to
intro,
don't
have
to
you.
Yeah
have
a
using
statement
for
interrupt
services.
E
A
A
A
D
A
Yeah,
I
would
argue
it's
not
as
nice
as
the
string
one
from
a
from
a
readability
standpoint,
because
for
the
most
part
you
will
not
have
them
as
literals.
You
will
have
them
as
a
cons
somewhere
and
that's
fine,
but
then
you
just
reference
your
const
everywhere,
because
you
probably
have
the
same
answers
across
all
of
them,
but
like
the
thing
is
that
even
if
you
have
them
as
a
as
a
literal
like,
I
don't
think
it's
it's
that
bad.
I
mean
there
was
a
whole
discussion
we
had
with
jan
about
do.
A
We
have
four
version
numbers
in
the
attribute,
or
do
we
just
have
a
string
based
one
for
the
version
number
and
the
general
push
there
was
strings,
are
much
more
compact
and
easier
to
read
than
you
know,
version
number,
comma
version,
number
comma
version
number
right,
but
like
regardless
of
this
I
mean
os
platform
has
shipped
so
like
for
better
worse,
you
put
it
interrupt
services
so
like
I'm,
not
sure
that
moving
like
we
can't
move
the
tide.
The
best
we
can
do
is
duplicate
the
type,
and
I
don't
think
that
that's
a
good
idea.
A
A
Well,
I
mean
the
question
is,
like
you
know
what
so
you
know,
as
I
said,
like
my
general
assumption
was-
and
you
can
correct
me,
but
like
the
the
basic
idea
was
with
os
platform,
the
only
thing
you
you
get
to
check
is
which
os
are
you
running
on
right?
That
was
the
whole
idea
of
runtime
information.
A
A
Yes,
but
like
existing
code
is
existing
code
anyway,
so
that's
not
a
concern,
and
so
the
behavior
we
can
have
is
we
can
say
if
you
call
israel's
platform
or
later
quote,
windows
quote
without
a
version
number
we
can
make
this
equivalent
to
calling
is
os
platform.
So
even
people
who
are
just
you
know
checking
whether
you
know
can
I
can
I
call
the
registry.
They
don't
have
to
go
to
runtime
information
either.
We
can
just
tell
them,
like
you
always
use
os
platform
more
later,
and
that
will
work.
A
That's
not
bad
as
a
compromise.
I
guess
I
mean
my
my
my
general
question
to
jan
was
like
let's
say
we
even
have
those
overloads
in
a
hot
loop.
Are
they
fast
enough,
or
am
I
basically
ending
up
caching
anyway,
in
which
case
we
are
probably
just
better
off
just
saying
just
call
the
api
once
assign
it
to
a
read-only
field
and
then
use
that
one,
and
then
we
just
make.
E
I
think
that
also
depends,
I
think,
the
natural
way
people
are
going
to
write.
The
code
is
with
the
check
inline
rather
than
caching
it
and
they're
only
going
to
cache
it
once
they
realize.
Hey
the
jit's,
not
optimizing
this,
and
then
I
think
the
natural
case
would
be
log,
a
bug
saying
this
isn't
optimized,
rather
than
caching,
into
a
field.
E
When
cases
like
like
mono's
llvm
and
the
aot
side
will
be
constant,
folding
it
regardless,
because
they
have
the
time
and
capability
to
do
more
in-depth
analysis.
C
Honestly,
if
I
were
using
these
apis
for
for
simplicity,
I
would
want
the
apis
to
be
called
like
environment
dot
is
windows,
environment,
dot
is
linux,
environment,
dot
is
ios
and
then
take
an
optional
version
number
after
that,
like
that's
far
easier
than
environment.oh
is
os
platform
or
later
os
version.windows.
C
D
C
C
E
C
I
mean
what
what
I'm
doing
is
I'm
looking
at
what
we
have
in
our
unit
tests,
where
our
unit
tests
define
helper
functions
for
all
the
various
os's
that
we
care
about,
and
I'm
just
thinking
like
our
actual
customers
are
going
to
do
the
exact
same
thing
like
no
one's
going
to
call
these
apis
with
hard-coded
values,
they're
going
to
wrap
it
inside
of
helper
methods.
E
C
E
Any
is
there
any
reason
why
we
couldn't
compromise
on
what's
exposed
here
by,
rather
than
necessarily
exposing
all
platforms
always
expose
the
common
ones,
so
windows,
linux,
mac,
ios
and
android,
and
then
have
a
general
purpose,
string
version
that
also
supports
you
know
any
arbitrary
ones
added
in
the
future.
E
A
Ios
yeah
so
don't
be
wrong.
I
have
no
problems
with
hard
coding,
those
it's
just
that
the
problem
that
I
have
is
it
seems
weird
to
dump
them
all
in
environment.
A
D
D
C
E
D
D
What
it
there's
reasons
why
we
went
with
the
is
os
platform
style
right
for
extensibility
in
the
future
so
like
today
you
can
say
you
know
os
platform.create,
freebsd
or
you
know
a
bunch
of
things
that
we
didn't
originally
care
about
right,
even
if
you're
on
netgore
app
too,
when
we
don't
have
a
free,
sb
one.
D
E
E
E
Well,
if,
if,
if
the
one,
the
one
that
takes
a
string,
can
still
more
easily
be
folded
than
the
one
that
takes
os
platform,
because
you
can
e
you
can
the
the
jit
itself
and
il
support
string
constants
it
they
don't
support,
struct,
constants
and
so
it's
trivial
to
say.
E
D
D
E
Like
someone
someone's
free
to
say,
I
support
like
my
custom
operating
system
and
I've
ported.net
core
to
it,
and
I
expose
a
library
with
p
invokes
that
are
version
specific
and
they
want
all
of
that
to
just
work
and
that's
something
that
will
never
support
inbox
but
which
they
want
to
support
and
have
everything
light
up
correctly
on
their
own
stuff.
Would
our
analyzers
support
that?
D
A
E
C
A
A
A
Mean
like
the
reason
we
didn't
do
it,
because
people
suck
at
optionals
normally,
especially
when
there's
multiple.
A
C
C
E
E
E
C
E
C
E
C
That's
not
how
you
would
do
that
check
the
way
that
you
would
do
that
check
is
you
would
you
would
look
for
the
existence
of
the
recommended
thing
prefer
that,
and
if
that
doesn't
work,
then
check
for
the
existence
of
the
deprecated
thing
and
use
that
at
no
point
would
you
have
an
is
earlier?
C
E
A
C
A
Ever
use
the
version
numbers
in
this
case
you
would,
if
a
newer
api
exists,
you
would
just
use
the
newer
api,
but
in
some
cases
apple
doesn't
have
a
replacement
api
because
the
replacement
is
behavior
or
configuration
or
some
other
stuff.
So
you
can't
check
for
the
other
thing
you
can
only
check
for
is
this
thing
removed.
C
D
A
I
mean
that's,
you
basically
make
the
argument.
If
people
were
to
write
version
checks
correctly,
then
we
wouldn't
have
this
problem,
but,
like
that's,
not
reality
right
like
that's.
Why
windows
developers
have
never
been
able
to
compare
four
version
numbers
correctly
right,
so
they
I.
I
have
little
doubt
that
what
you
just
said
about.
Why
can
I
just
negate?
It
is
number
one
thing
people
will
do
and
then
it
will
be
very
confused
why
it
doesn't
work
on
other
platforms.
E
This
really
seems
like
a
conversation
of,
do
we
expose
10
overloads,
which
is
you
know,
the
10
platforms
and
just
is
later.
Do
we
expose
20,
which
is
right?
The
10
platforms
is
later
in
is
earlier.
Do
we
expose
80,
which
is
all
of
the
variance
but
exp,
which
is
just
the
is
later
but
exploded
without
optional
parameters,
or
do
we
expose
160,
and
I
think
the
best
compromise
is
just
expose
the
20
with
the
optional
and
wait
for
people
to
complain
about?
A
A
C
C
A
A
Everything
else
goes
to
the
general
method,
and
the
problem
is:
when
you
have
exceptions,
people
will
generally
not
know
what
to
do,
because
it's
an
exception
to
begin
with
right,
it's
not
something
that
they
do
normally
and
now
it's
basically
completely
uniform,
but
it
doesn't
matter
whether
you
check
for
the
presence
of
a
new
api
or
with
an
api
go
to
obsolete
and
api
go
deprecated.
It's
always
the
same
pattern,
and
that
I
think,
if
we
can
make
that
work,
I
think
that
would
be
preferable.
A
E
A
E
Oh
yeah,
that's
fair,
and
so
then
linux,
freebsd
and
others,
since
we
don't
have
large
scenarios
for
them,
we
wouldn't
have
explicit
accelerators
for
them.
People
would
just
use
is
os
platform,
and
if
enough
people
asked
for
it,
we
could
then
add
an
accelerator.
A
E
I'm
I'm
not
convinced
that
there
is,
you
could
just
have
them
all.
Ford
is
os
platform
or
later
in
iso's
platform
or
earlier,
and
then
oh.
A
E
E
A
E
How
do
I
know
about
the
spellings
that
should
go
in
here?
It
should
just
be
any
case
and
whatever
the
rid
is
we
we
have
a
documented
page
with
all
the
platform
it's
and
I
would
presume
we
would
be
expanding
that,
as
as
we
support
more
like
tv
os.
D
A
No,
I
think
the
general
expectation
is
like,
if
you
have
a
build
of
this
thing
like
somebody
must
have
done
work
right.
If
the
fbsd
folks,
for
example,
implemented
this,
they
underhook
to
return,
is
os
platform
string,
freebsd,
true
right,
they
have
to
write
that
code,
like
somebody
clearly
knows
like
what
the
os
is
right,
and
I
think
the
expectation
then
is.
E
D
D
A
We
would
have
an
is
os
platform
api
that
just
takes
platform
right
and
say
whether
we
haven't
just
in
his
windows.
It
takes
no
arguments
and
that
one
can
still
say
yeah
you're
on
linux.
I
can't
give
you
a
version
number,
because
that's
not
really
a
thing
here,
but
if
you
really
want
to,
we
can
give
you
the
kernel
version
number,
but
then
I'm
I'm
doubtful
that
this
would
be
useful
right,
because
we
I
mean
I'm.
E
A
Well,
I
mean
to
eric's
point
I
mean
I
fundamentally
that's
why
I
I'm
questioning
the
wisdom
of
putting
it
on
an
on
environment
if
we
had
a
dedicated
type
whose
whole
purpose
in
life
is
the
westchecks,
I
don't
mind
having
a
method
per
operating
system
like
if
we
have
no
problem,
adding
an
eno
member
to
os
platform
to
the
os.
We
should
have
no
problem
with
adding
is
tv,
os,
stbrs
or
later
http
os
earlier
then
like?
That
seems
completely
reasonable
to
me.
A
E
I'm
I'm
still
like
that's
overkill,
because
environment
is
telling
you
info
about
the
environment,
the
environment's
always
going
to
be
super
complex.
It's
just
like
the
cpu,
the
cpuid
function.
It
has,
you
know
at
least
50
different
functions.
Many
with
sub
functions
to
query
all
the
information
about
the
cpu.
E
A
A
A
Well
either
that
or
I
mean
we
mean
we
gave
a
various
options
like
we
could
make
them
static
methods.
On
some
time
we
could
literally
say
we
use
the
operating
system
thing
we
already
have
and
make
them
static
methods
there
right
that
wouldn't
be
terrible,
where's
operating
system
defined.
I
think
it
isn't
system
right.
Yes,.
A
A
D
A
E
A
E
Mac
and
will
on
ios
no
like
version
itself
when,
where
it
it
does
comparisons
weird
when
something
specified
versus
not
you
mean
system.version
uh-huh
system.version,
like
it
tracks
what
it
uses
a
value
of
negative
one
to
indicate
this
value
wasn't
assigned
and
it
treats
that
differently
from
passing
in
an
explicit
zero.
So
if
you
actually
do
new
version,
10
0,
that's
treated
differently
from
new
version
100.
A
Let's
not
get
too
hung
up
on
where
we
put
it.
Let's
first
agree
on
like
what
methods
you
want
and
then
we
can
decide
where
to
put
them.
Like
I
mean
I
just
tossed
the
operating
system
as
an
idea,
because
it
seems
like
it's
a
you
know,
the
code
reads
decent
right
and
it
seems
like
it's
easy
to
explain
that.
That's
what
the
type
is
for
and
having
them
aesthetics
is
also
not
really
a
huge
deal,
because
if
you
say
operating
system
dot
blah,
you
only
see
the
aesthetics
right.
A
C
E
I
agree,
except
for
the
I
don't
think
it
would
be
polluting
environment.
I
think
that's.
It
fits
cleanly
in
with
everything
else
that
environment
exposes
today,
and
it
would
continue
to
do
so,
no
matter
how
many
platforms
we
support
in
the
future,
because
it's
still
describing
the
environment
and
it's
probably
the
first
place.
People
are
going
to
look
for
something
like
this.
It's
already
where
people
look
for
and
get
things
like
os
version
and
is
64-bit
operating
system
and
the
processor
count
and
the
environment
variables
and
everything
else.
D
The
issue
that
I
have
is
like-
and
this
is
my
uber
feedback
about
this-
is
we
tried
with
runtime
information
right
like
that
thing?
Isn't
that
old
and
we're
already
saying
we
screwed
up
and
we
screwed
up
in
a
couple
ways.
Apparently
one
is
we
put
in
the
wrong
name
space
which,
if
you
do
that
now
that
means
that
type
is
dead
forever.
Right,
like
we,
we
no
longer
like
a
type.
Is
that
it's
in
the
wrong
name
space
and
then
two
like.
A
C
D
A
D
A
Well,
we
that's
what
we
talked
about
this
for
years,
but,
like
I
I'd
rather
not
bet
a
feature
on
this
because
that's
not
going
to
happen
anytime
soon,
like
I
think
to
me,
the
argument
with
runtime
information
is
kind
of
different,
like
I
would
say
we
screwed
up,
but
we
screwed
up
unknowingly
because
it
was
for
a
different
design
right.
The
whole
point
of
runtime
information
was
we
don't
give
you
the
us
version
number.
A
A
So
the
only
thing
we
give
you
is
to
tell
which
operating
system
here
or
not
what
version
of
the
operating
system
you're
on
and
then
we
give
you
these
weird
strings
that
you
can
use
for
diagnostic
purposes,
but
god
forbid
you
ever
want
to
parse
them,
and
that
was
the
design
because
it
was
kind
of
the
windows.
Guys
are
very
strong
on
their
shell
and
obversion
checks,
and
I
think
since
then
we
have
evolved
into
well.
A
First
of
all,
we
have
an
analyzer
now
that
it
can
actually
help
you
with
writing
correct
version
checks
and,
secondly,
like
I've,
yet
to
see
a
different
alternative
for
for
a
design
where
you
can
actually
check
for
the
presence
of
something
without
having
to
check
every
single
symbol
you're
using
and
that
one
doesn't
work.
So
you
need
something
else
that
correlates
them
together
and
realistically
that's
either
contracts
or
it's
version,
number
version
numbers
are
much
easier
to
tool
than
contracts.
A
So
I
think
fundamentally,
like
the
type
is
not
great,
but
it's
also
not
a
big
type
and
it's
also
not
a
type
that
has
a
lot
of
users
today.
So
it's
people
have
used
it
sure,
but
like
in
the
grand
scheme
of
things
compared
to
environment
or
operating
system,
the
usage
is
extremely
low,
so
I'm
not
entirely
like.
So
it
feels.
A
D
A
A
E
E
E
D
E
I
it's
I'm
completely
fine
with
that.
It's
just
worth
noting
that
that
basically
also
means
porting
like
the
architecture,
enum
and
other
stuff,
which
I'm
also
completely
fine
with.
I
think
it's
better,
especially
when
you
actually
have
to
think
about
things
like
32-bit
versus
64-bit
in
many
cases
or
arm
versus
x86
or
linux
versus
windows.
A
E
Why
not
take
the
the
breaking
change
of
basically
cloning
runtime
information
in
the
system?
You'd
have
a
conflict
that
people
would
have
to
work
around.
A
Yeah,
I
wouldn't
do
that,
like
think
of
the
normal
implications
of
when
people
talk
about
types,
people
don't
qualify
type
names,
they
say
like.
I
use
runtime
information
to
determine
the
operating
system,
and
then
it's
like
okay,
but
I
can't
get
this
to
work
well,
which
one
are
using
using
the
one
in
system
are
using
the
one
in
system
runtime
interrupt
services.
Like
I
mean
you
make
everybody's
life
harder.
If
you
have
the
exact
same
type
name
somewhere
else
like
it's.
Okay,.
C
And
surprise
tanner,
you
didn't
suggest
having
runtime
information,
subclass
environment
and
just
move
everything
down
to
the
base
class.
E
D
And
we
do
we
do
we
obsolete
runtime
information,
then
move
everything
from
runtime
information
into
environment.
Add
these
new
apis
we're
talking
about
and
obsolete
runtime
information.
Pretty
much,
maybe
not,
maybe
no.
We
don't
slap
on
the
attribute
yet,
but
it's
like
for
5.0.
It's
virtually
obsoleted,
we're
not
going
to
add
anything
new
to
this.
D
E
D
D
A
So
I
think
that's
the
one
thing
we
all
agree
in,
but
the
question
is
still
like
how
much
like
I
am
still
somewhat
concerned
that
we
basically
flood
the
type
like
I
mean
right
now.
We
have
10
but,
like
this
seems
like
a
fairly
unbounded
set
of
things
right,
because
I
mean
I
only
wrote
the
ones
that
are
mainline
but
like,
if
you
just
look
at
xamarin,
they
have
like
already
four
or
five
more
coming,
so
that
yeah,
I'm
not
sure
that
that
is
a
winning
proposition
to
have
this
unbounded
thing
on
an
environment.
A
A
D
A
So
I
don't
disagree
with
you,
but,
like
I
mean
four
again,
people
can't
check
major
like
major
minor
correctly
today.
It's
the
exact
same
the
same
thing
you
say
is
the
major
the
same,
and
it's
the
second
one
is
division
the
same
or
higher,
and
it's
the
second
one
higher
order
and
people
this
up.
All
the
time
too,
like
that's
why
windows
10
went
with
this
weird
thing
where
they
skipped
9x
right,
so
it's
yeah.
I
mean
I'm
not
disagreeing
with
you
that
in
principle,
that
code
is
readable.
A
It's
just
that
my
confidence
and
people
will
get.
This
right
is
very
low.
Now
you
could
argue
with
an
analyzer.
Maybe
it
doesn't
matter
because
we
will
flag
it
when
they
get
it
wrong
and
maybe
that's
the
way
to
do
it,
but
I
think
asserting
that
they
get
this
right.
I'm
I'd
like
to
see
some
evidence
for
this
because
all
evidence
we
have
points
to
the
contrary.
C
A
A
E
C
D
C
D
C
Were
like
we,
we
don't
when
we
design
apis,
we
we
clearly
don't
want
them
to
be.
We
don't
want
the
behavior
to
be
unpredictable
as
in
like
oh,
I
I
never
could
have
imagined
that
this
would
be
an
or
later
check,
but
for
this
type
of
api
like
it
is
reasonable
to
assume
that
it's
not
an
exact
version
match,
that's
a
version
match
or
later,
and
the
documentation
would
flesh
that
out,
like
the
having
or
later
is
reasonable.
I
guess
is
what
I'm
getting
at
here.
C
A
D
E
A
I
mean
you
could
make
the
argument
of
saying,
like
you
know,
would
we
so
mike
only
concerned
with
that
approach
of
moving
the
all
later
is
that
we
can
never
do
an
exact
version
match,
but
then
again,
would
we
ever
support
that,
because
that
seems
like
literally
providing
people
with
the
gun
to
their
head
right?
And
so,
if
you.
A
C
I
I
like
that
that
implies
that
there's
something
an
actual
os
family,
greater
than
windows
or
greater
than
ios
or
greater
than
android.
C
D
D
A
A
system
right
well
in
this
world,
I'm
still
proposing
to
leave
them
in
runtime
versioning,
but
like
I
because
that's
where
the
other
ones
are,
but
I
don't
feel
super
strongly
like
if
we
I
we
generally
don't
want
to
dump
everything
in
system,
because
it's
already
a
dumping
ground
for
things
and
and
this
system
runtime
versioning,
isn't
a
bad
namespace
like
it
doesn't
have
much
stuff
in
it.
To
begin
with,
like
I
just
my
primary
motivation
is
getting
people
to
not
import
runtime
interrupt
services
because
it
will
bring
in
a
ton
of
stuff.
D
D
A
A
D
From
like
the
other,
the
other
complaint
I
have
about
it
is
supported.
Operating
system
has
like
system.runtime.versioning
is
about
the
version
of
the
runtime,
where
the
runtime
is
the
net.
Runtime
right
and
supported
operating
system
attribute
has
nothing
to
do
with
that,
like
it
just
feels
like
the
wrong
name,
space.
D
A
D
If
these
apis
were
in
runtime
information,
I
would
think
the
attribute
should
go
with
the
same
type
as
runtime
information.
These
apis
are
proposing
to
be
on
environment.
So
that's
why
I
think
these
attributes
should
go
with
environment,
but
they
work
together,
so
they
should
be
in
the
same
name
space.
That's
my
reasoning.
A
Yeah,
I
think
that's
not
entirely
the
way
we
see
this,
because
the
thing
is
we
have
done
this
in
other
places
where
we
basically
say
there
is
advanced
things
that
we
should
be
shoving
in
nested
namespaces
right.
So
I
think
there
is
a
great
deal
of
code.
You
can
write
that
does
not
actually
involve
putting
attribute
on
your
own
stuff
and
so
there's
still
a
difference
between
who
applies
the
attribute
and
who
reads
the
attribute.
A
Well,
the
problem
is
methods
or
the
the
benefit
is
you
know
if
you
have
put
something
on
an
existing
type,
it's
already
in
the
namespace
right,
which
is
the
type
right,
so
you
only
see
it
when
you're
actually
dotting
into
environment,
everything
that
you
put
type
wise,
it's
always
visible
and
that's
why
it's
a
bit
more
of
a
problem
for
for
types
than
it
is
for
members,
because,
like
look
at
this
namespace
today,
right,
if
you
look
at
your
system
like
there
is
a
whole
bunch
of
stuff
in
there
that
arguably
doesn't
apply
to
a
great
deal
of
stuff
right.
A
So,
like
you
know,
underscore
app
domain
comes
to
mind
or
you
know
the.
What
else
do
we
have
here
like
the
the
typical
stuff
that
we
put
there
like?
You
know
generic
uri,
parser
and
stuff,
and
it's
like?
Is
this
really
relevant
for
everybody
all
the
time?
The
answer
is
no.
It's
just
that
we
didn't
really
think
about
when
we
put
stuff
in
the
environment
and.
A
So
you're
basically
making
the
observation
that
we
up
in
the
past,
but
that
to
me
is
not
a
justification
to
do
it
in
the
future.
Right
I
mean
the
polymer
system
already
is
too
crowded
right
so,
like
we
have
a
lot
of
stuff
in
there
that
we
wish
we
wouldn't
have
put
there
and
then
there's
stuff.
We
wish
we
would
have
put
there
which
we
didn't
like
like
like
string
builder
right.
A
A
A
D
A
D
D
Are
going
to
use
these
attributes
a
lot
to
tell
you
the
honest
truth
like
the
way
I
would
write
this
code,
or
at
least
the
way
I
think
I
would
write
this
code
is
that
have
like
one
method
that
would
do
my
versioning
checks,
if
is
whatever,
and
then
I'd
call
a
method
that
I
knew
that
I
was
in
ios
now
and
I
would
just
slap
on
I'm
on
ios
now
attribute,
and
now
I
just
can
call
any
ios
attribute.
I
want
or
method
that
I
want.
A
D
The
a
real
question
is:
how
often
do
you
only
do
one
line
of
code
inside
that,
if
check
right?
Normally,
it's
you're
gonna
write
an
if
check,
and
then
you
know
they're
like
say
you
want
to
do
something
with
the
I
don't
know
the
gps
or
the
compass
or
something
like
that
right,
where
you
want
to.
You
need
to
call
specific,
ios
or
android
apis
you're,
not
just
going
to
write
one
method
or
one
one
line
inside
the
diff
check.
D
D
A
Yeah,
I
guess
I
mean
the
way
I
justify
runtime
versioning
in
my
head
is,
I
would
just
say
it's
the
way
the
runtime
versions
thinks,
and
that
includes
the
os
right.
So
I
don't
think
it's
that
bad,
but
it
I
give
you
that
it's
very
contrived
right
but
like
yeah
to
me,
it's
like
so
to
me
really
the
the
the
two
extremes.
Are
I
don't
like
interrupt
services,
because
it's
a
bunch
of
garbage,
I
don't
want
to
pollute
system,
and
so
everything
in
between
is
fair
game.
A
I'm
also
I
mean
we
could
create
a
new
namespace
if
we
really
wanted
to
too.
That
might
be
overkill
because
I
don't
know
what
would
call.
A
A
A
A
E
A
Yeah,
I
mean
that's
what
I
I've
actually
thought
the
feature
requests.
I
don't
think
it's
going
anywhere
but
yeah,
but
even
if
we
had
one
right
like
it
would
look
very
similar
to
what
we
currently
have.
My
biggest
concern
is
like
I,
don't
mind,
duplicating
methods.
I
really
don't
like
duplicating
types.
A
A
E
E
Either,
though,
because
you
like
on
windows,
you
fundamentally
need
to
know
at
times
am
I
a
64-bit
process
or
a
32-bit
process
on
a
64-bit
operating
system
because
well
well,
99-point,
like
nine
to
six
digits
percent
of
things,
work
identically
in
cis
wow
mode?
There
are
things
that
work
differently
in
which
you
may
need
to
explicitly
codify
around,
such
as,
if
you
want
to
from
a
32
bit
process
access
the
actual
64-bit
program
files
folder.
So
you
can
launch
a
64-bit
process
from
your
32-bit
process.
A
A
D
A
So
how
do
we
feel
about
the
the
methods
then?
So
what
I
currently
have
is,
I
basically
have
is
os
platform
is
windows
is
ios,
is
mac,
os
is
android
and
then
whatever
four
other
email
members
we
have
on
os
platform
and
then
the
os
platform,
one
takes
a
string
and
four
optional
versions,
and
everybody
else
just
takes
four
optional
versions.
E
D
But
having
two
isn't
so
bad
right
where,
if
it's
just
is
ios
and
then
is
ios
or
later,
and
then
you
there,
your
major
at
is
required
right
because
there
wouldn't
be
any
sense
to
not
put
a
major
in
there
and
then
three
optional
links.
And
then
we
just
have
two
per
os
platform
that
we
support
inbox.
So.
E
E
E
Is
os
platform
and
is
oep
is
os
platform
at
least,
and
then
you
would
for
the
specific
ones
like
windows.
It
would
be
called,
is
os
platform
windows
and
is
os
platform
at
least
windows,
then
they're
all
grouped
together
and
whether
you
use
a
string
constant
or
the
overload
that
doesn't
take
a
string.
They
logically
read
the
same.
E
C
E
D
A
Yeah,
no,
I
don't
have
os
platform
prefixes.
For
those
I
mean
all
the
specific
ones.
Just
this
is
operating
system
and
then
that's
it.
So
it's
is
windows
is
windows
or
later
is
ios
as
ios
or
later
is
mac.
Os
is
mac,
oso
later
is
android
is
android
or
later,
and
then
the
only
other
one.
We
have
is
isos
platform
and
is
west
platform
or
later.
C
E
It
makes
it
so
you
don't
have
to
remember
what
the
actual
name
of
the
os
platform
is.
Then
you
only
have
to
use
the
string
version
when
you
need
to
consider
something
that
we
don't
have
a
convenience
method
for
so
maybe
someone
exposes
a
custom
platform
or
something
see.
A
E
A
A
E
C
B
B
A
B
Would
it
have
made
sense
to
have
the
enum
in
system
console
under
name
like
console,
console,
behavior
or
sorry
color,
behavior
and
then,
if
in
the
future,
there
was
to
be
because
there
was
an
issue
related
to
what
we
had
so
then,
maybe
that
would
have
been
used
later
and
then
email
also
said
that
they
might
have
been
there
there's
they
have
thoughts
of
adding
a
similar
enum
later
in
console.
So
why
not
just
add
it
now?
But
if
that
doesn't
make
sense,
then
we
can
just
keep
it
as.
A
A
My
console
system
console
yeah,
I
mean
like
yeah.
I
would
not
do
that
because
it
seems
like
it's
not
an
abstraction
for
logging.
I
mean
that's
what
I
said
originally
like.
If
you
wanna,
if
you
wanna,
reuse
the
enum
on
the
on
the
console
type,
then
it
logically
belongs
to
the
system
right
unfortunately,
but
like
there's
another
type
here
to
the
system
space
but
like
yeah,
I
mean,
if
you're
not
doing
this
now,
then
I
think
it's
probably
fine
to
keep
it
like
that.
B
Time
frame
would
couldn't
we
just
have
by
default
yeah,
but
that's
a
I
think.
B
Eric's
point
earlier
on.
C
A
Yeah,
I
think
the
I
mean
my
concern
generally
speaking,
is:
if
we
do
the
system
console
work
now,
then
I'm
fine
with
that,
but,
generally
speaking,
I
would
be
very
careful
with
doing
half
of
the
console
work
now,
but
providing
all
the
apis
now,
because
if
you
don't
have
the
entire
feature,
the
chance
of
getting
the
api
right
is
not
very
high.
Usually.
C
A
That
make
sense
for
the
logger,
but
not
the
console,
and
then
you
end
up
with
duplicated
types
anyway,
so
without
a
full
design
it's
hard
and
that
to
me
the
the
most
targeted
thing
would
be.
The
worst
that
can
happen
is
the
logger.
Behavior
type
becomes
obsolete
in
a
few
releases
because
we
fixed
our
console,
but
given
the
configuration
system,
I
I
doubt
that
that's
true.
A
A
Let
me,
after
the
proposal
to
actually
have
the
shortened
method
names,
then
we
can
bike
and
actually
let
me
extend
it
to
everything
we
have
in
the
west
platform
as
well
to
basically
look
at
what
the
what
the
final
version
would
look
like,
and
then
we
can
decide
whether
we
think
we're
overflowing
environment
or
whether
we
should
do
something
else.
D
A
Oh
yeah,
like
I
mean
even
for
environment,
I
would
not
propose,
is
os
platform
windows.
I
I
I
still
like
the
shorter
names.
It
seems
more
aesthetic,
but
it
does
have
the
problem
that
you
split
it
all
over
the
place.
But,
like
again,
I
could
be
convinced
that
that's
just
the
pattern
of
environment
right
there,
we
just
say
I
mean.
D
A
Right,
I
mean
yeah,
as
I'm
saying
I
think
it
could
be
convinced
of
saying
environment
is.
Is
your
pattern
to
ask
questions
about
the
environment
you're
in
and
it
will
have
operating
system
and
architecture
in
it?
And
then
they
are.
You
know
they're,
basically
based
on
how
they're
how
they're
sorted
right,
so
you
have
like
half
the
half
the
at
least
one
are
at
the
top,
and
then
you
have
the
ios
when
android
once
splinter
all
over
the
place
right,
but
I
think
that's
fine,
I
think
that's
probably
not
too
bad.
D
I
wouldn't
I
I
guess
I
wouldn't
prefix
at
least
I
think
I
think
a
postfix
at
least
is
better
or
suffix
like
I,
I
kind
of
like
is
windows
version
at
least
blah.
I
think
that
reads
perfectly
fine,
and
then
the
group,
and
then
their
group,
the
windows
ones,
are
grouped
together.
Right,
you
have
is,
windows
is
windows.
Version,
at
least
is
ios
is
ios
version,
at
least.
A
D
D
A
A
E
C
Sure,
whatever
the
I
guess,
what
I
what
I
was
coming
down
to
was
I
I
want.
I
want
all
of
the
os
checks
to
be
grouped
within
the
same
family
like
I
want
the
android
checks
to
be
grouped.
I
want
the
ios
checks
to
be
grouped
and
so
on.
Tanner's
proposal
of
having
is
os
platform
blah
also
solves
that
problem.
Additionally,
it
keeps
all
of
the
family
checks
themselves,
grouped
not
just
within
each
family.
C
What
what
I
meant
was
that
tanner's
suggestion
of
having
is
os
platform
windows
as
os
platform
ios.
All
of
those
different
family
groups
are
now
together
because
of
the
is
os
platform
prefix.
I
just
think
it's
a
bit
verbose,
but
it
does
solve
that
side
problem
nicely.
A
A
If
you
ever
do
the
negation
you
have
environment,
dot
is
os
and
not
is
the
other
side
of
it.
So
I
would
try
to
not
put
in
like
a
super
long
string.
A
A
A
C
C
C
C
C
I
don't
think
they're
part
of
this
proposal.
I
I
was
just
saying
it
is
a
slight
distinction
between
our
case
and
the
platform
sdk
right.
A
C
D
A
A
C
C
D
A
C
E
Yeah
is
os
platform
at
least
windows
and
is
os
platform
windows.
It's
my
favorite,
but
my
second
favorite
was
is
android
and
is
android
version
at.
A
A
A
Okay,
let's
get
back
to
the
drawing
board,
then
I
will
propose
that
and
let
me
run
through
some
code
samples
that
people
actually
use
to
check
the
various
supported
and
unsupported
combinations
to
make
sure
that
we
can.
The
analyzer
can
actually
handle
that
and
that
it
makes
sense
to
us
in
code,
but
I
think,
is
android
and
not
his
android
version.
At
least
it's
probably
reasonable.
D
D
A
D
A
D
A
A
A
A
A
C
C
So
if,
if
somebody
defines
their
own
method,
I
am
debian,
you
know
1.2
or
later.
E
C
C
We
don't,
but
I
wonder
if
we
need
it
so
so
to
take
these
accelerators
right
now.
Right
does
the
the
accelerators
that
we
just
defined
in
this
meeting?
Does
the
code
analyzer
that
we
have
have
to
be
aware
of
these
accelerators,
or
can
we
somehow
annotate
the
accelerators
such
that
the
analyzer
honors
them.
C
Yeah,
but
what
I'm
saying
is
if,
if
us
defining
our
own
accelerators
here
created
work
for
the
analyzer,
then
other
people
defining
their
own
accelerators
will
also
create
work.
Does
that
mean
other
people
won't
be
able
to
define
their
own
accelerators
without
us?
Putting
those
accelerators
into
the
box.
A
C
For
I,
maybe
because
it's
a
platform
that
we
haven't
defined
an
accelerator
for
or
you
want
to
bake
the
version
numbers.
And
yes,
I
if,
if
utility
dot,
is.
C
Anybody
know
1922,
it's
I
don't
know
it's
three
years
old.
I
think
so.
A
C
A
Or
it
you
know
up
to
four
ins,
I
think
it
would
be
okay
to
say
you
take
less,
but
as
always
major
minor
build
revision
in
that
order.
So
you
only
take
two,
then
you
can
only
check
for
major
minor
and
then
the
other
one
would
be.
If
you
want
to
have
a
dedicated
one
for
the
whole
thing,
then
you
would
do
that.
C
Yes,
something
like
that
would
work
yeah
you,
you
wouldn't
be
able
to
do
less
than
checks,
but
maybe
that's.
Okay
for
these
kinds
of
accelerators.
A
Well,
we
basically
said
like
well,
I
think
it
would
be
implied
right.
I
think
windows
threshold
would
have
the
same
semantics,
as
is
windows
at
least
10
0
1922,
but
I
think
we
would
just
say,
like
you,
don't
get
to
do
exact
matches
either,
but
we
only
have
one
set
of
semantics
and
this
matrix
are
always
it's
an
at
least
check
and
yeah.
The
person
names
the
method.
So
if
they
don't
want
to
suffix
it
at
least
then
they
don't
do
it
sure.
A
C
Yes,
yeah,
but
this
this
os,
or
this
os
check
attribute
that
you
just
put
on
is
new
api,
correct.
A
Yeah,
it
would
be
yeah,
it
would
be
a
new
attribute,
and
so
my
concern
with
that
is
this
kind
of
we
would
have
to
so
that
might
be
very
expensive
for
us
to
check
right
because
right
now,
what
ends
up
happening
is
the
analyzer.
The
way
it
works
is
we
first
check.
Does
the
method
body
call
any
api
that
has
attributes
on
them,
meaning
it's
it's
an
it's
an
it's
a
specific
one.
A
If
so,
then
mark
this
method
for
neat
flow
analysis,
and
then
we
do
floor
numbers
for
the
method,
and
then
we
say:
okay
in
the
point
where
you
call
this
our
specific
api,
do
you
have
an
os
check
right
and
so
then
we
basically
walk
all
the
methods
that
you
know
are
basically
guards
and
if
statements
or
control
flow-
and
then
we
say
okay,
are
they
actually
capability
apis
and
if
so,
what
do
they
actually
ensure?
A
And
so
presumably
that
no
means
we
have
to
look
at
every
method
and
then
have
to
say
well,
it's
the
method
attributed.
If
so,
okay,
we
invert
the
capability
api,
it's
probably
not
too
bad,
because
it
still
is
not
all
the
code
that
runs
and
realistically
the
most
expensive
thing
that
runs
is
the
flow
analysis,
but
yeah.
I'm
just
wondering
like
how
valuable
is
this
stuff,
given
that
one,
it's
complexity
and
two,
it
doesn't
seem
like
a
lot
of
people,
would
do
that.
C
A
B
A
C
A
So
we'll
see,
but
basically
I
guess
the
idea
would
be.
If
we
do
that,
I
I
think
if
we
have
the
analyzers,
I
saw
the
the
accelerators,
I
think
we're
on
the
hook
to
keep
providing
them.
A
Design
where
we
can
just
add
them
all
all
the
time
without
having
to
justify
wall,
it's
just
used
enough
that
we
actually
need
an
accelerator.
For
that.
I
would
just
always
have
them
sure,
and
then
the
need
would
be
lower,
because
realistically,
when
would
you
need
an
accelerator
out
of
band?
Basically
right
and
then
the
answer
might
be
no
right
and
we
always
have
the
you
know:
hot
wired,
one
that
you
can
use
temporarily,
because
it's
a
built-in
flight
or
something,
but
I
don't
think
people
would
define
their
own.
Then.
C
A
Yeah,
the
one
downside
with
not
using
strings.
Is
you
can't
you
can't
extract
them
easily
right?
That
was
a
nice
thing
with
strings.
You
could
just
define
locals
or
well.
C
A
E
A
C
A
Well,
like
I
mean,
but
that's
what
I'm
saying
right
like
to
me,
the
argument
would
be:
yes,
we
want
code
to
read
nice,
that's
why
we
provide
accelerators
right,
but
it
doesn't
mean
that
we
have
to
have
an
extension
point
that
you
can
define
arbitrary,
accelerators
right,
because
now
you
become
this,
you
know
meta
configuration
problem
where
it's
like.
How
do
you
tell
the
analyzer
that
this
is
a
an
actual
capability
check,
api
right?
A
C
And
baby
plane,
yeah,
and
maybe
maybe
that's
you
know
the
best
we
can
do
right
now.
If
so,
if,
if
somebody
does
define
their
own
analyzer,
what
would
we
tell
them
in
order
to
get
the
anal?
I'm
sorry
if
somebody
defines
their
own
accelerator,
what
is
our
guidance
to
that
person
in
order
to
get
the
analyzer
to
stop
flagging
it?
Will
we
just
tell
them,
suppress
this
warning
around
the
call
sites.
A
A
Yeah,
I
mean
that's,
I
guess
I
struggled
with
that.
A
little
bit
I
mean,
like
I
understand,
you're
concerned
with,
like
we
should
just
make
the
analyzer
work,
but
there
is
also
the
the
argument
of
like
okay,
how
how
many
wiggles
and
and
gears
do
you
give
people
to
customize
their
code
right,
because
you
also
want
to
make
an
analyzer
that
is
actually
fast
right,
because.
C
A
Yeah,
that's
totally
fair.
I
mean
like
the
person
that
uses
the
code
base.
Is
you
know
they
decide
what
they
want
to
do.
The
the
thing
here
was
basically
the
idea
that
you
know
if
you
are
coding
against
the
bleeding
edge
all
the
time,
then
there's
just
no
way
you
get
these
version
numbers
right
and
that's
the
other
thing.
A
So
if
the
version
numbers
keep
changing
like
which
is
kind
of
the
thing
on
ios
and
android,
then
writing
your
own
accelerators
is
probably
also
losing
battle,
because
you
keep
defining
them
versus
an
our
code
base.
They
are
somewhat
stable
right
because
the
our
support
matrix
doesn't
change
drastically
over
time
versus
on
ios.
It
actually
does
because
they
pull
you
forward
all
the
time.
A
C
A
I'll
point
this
out
and
then
I'll
update
this,
and
then
we
can
approve
it
next
week.
If
we're
happy
with
that
cool,
I
think.
That's
everybody!
Everybody!
That's
already
left,
probably
right.
C
Your
life
kind
of
interesting,
the
the
ebb
and
flow
of
these
things
like
who
tends
to
dominate
the
conversations
from
minute
to
minute
to
minute.
A
D
A
A
A
A
Sure
we
will
enjoy
your
weekend
and
do
whatever
whatever
it
takes
all
right.
You.