►
From YouTube: 2020-11-20-Node.js N-API Team meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
napi
team
meeting
for
november
20th
2020
we'll
follow
our
standard
approach
of
looking
at.
What's
on
our
milestone
11,
but
I
guess
we
have
a
couple
things
that
aren't
necessarily
on
there
that
we'll
start
out
with,
I
think
gabriel.
You
wanted
us
to
kick
off
with
talking
about
the
inheritance,
pr
that
you've
opened
right.
B
Yep,
so
this
this
issue
of
being
able
to
inherit
from
arbitrary
javascript
classes
has
has
sort
of
come
up
off
and
on
in
the
past
two
years
or
so,
and
we
don't
have
support
from
from
the
engine
for
doing
this,
at
least
not
from
v8,
and
so
when
it
came
up
again,
I
figured
I
I
should
try
to
settle
the
issue
once
and
for
all,
and
so
I
wrote
a
pr
where
it
inheritance
is
achieved
by
generating
a
javascript
string
at
runtime
and
basically
every
property,
whether
it's
instance
or
or
static
of
a
class
is
basically
declared
in
javascript.
B
But
the
javascript
calls
a
native
function,
which
is
passed
in
as
a
parameter
to
the
function
that
that
that
is
being
executed
and
written
in
javascript
at
runtime.
And
so
that's
basically
it
it's.
I
know
it's
a
it's.
A
big
change
and
and
anna
has
already
sort
of
vetoed
it,
which,
which
is
completely
understandable
because
it
may
or
may
not
belong
in
core.
A
Was
it
functionality
that
was
in
in
nan.
B
Yes,
because
yeah,
I
I
I
don't
think
in
nan
one
could
inherit
from
from
javascript
classes
either
because
there
is
no
function
template
for
a
javascript
class.
The
the
fundamental
problem
that
for
which
we
would
need
engine
support
is
that
the
in
inheritance
in
v8
can
only
be
achieved
if
one
has
access
to
the
the
parent
function.
Template
which
this
dysfunction
template
thing
is
a
purely
v8
concept.
B
It's
not
part
of
any
spec
right,
but
that's
how
va
does
classes,
and
so
one
needs
to
have
access
to
that
which
one
does
not
have
after
the
fact.
So,
if
you
create
the
class
yourself,
then
obviously
you
have
access
to
the
function.
Template
because
that's
how
one
creates
classes,
one
creates
a
function,
template
and
then
one
retrieves
the
function
from
it
and
that
function
becomes
the
javascript
constructor
for
that
class.
But
given
a
constructor,
one
cannot
retrieve
the
template.
B
So
that's
that's
the
fundamental
problem,
and
so
so
this
was
not
possible
in
nan,
either.
Okay,
but
now
we
have
things
like
event
target
which
we
didn't
have
back
in
the
nan
days,
which
you
know
folks
may
want
to
subclass,
because
that
is
the
you
know
a
lot
of
the
web
idle
says.
You
know
you
know
class
or
interface
abc
colon
event
target.
B
So
you
know
the
the
web
ideal
dictates
that
it
is
to
be
a
subclass
of
event
target,
and
so
you
know-
and
and
if
we're
going
to
implement
other
web
apis,
then
this
will
become
even
more
relevant.
B
So
so
that's
that's
one
reason
it's
coming
up,
so
I
I
saw
this
in
in
web
it'll
nappy
as
I
was
working
on
it.
So
web
gpu
needs
this,
and
you
know
just
in
general,
it's
it's!
It's
come
up.
There
have
been
at
least
five
or
six
requests
over
the
past
two
years
for
this
and
they've
come
up
and
then
they've
been
they've,
come
back
and
napped
again.
B
A
B
What
was
I
gonna
say?
I
lost
my
train
of
thought
now
there
was
one
other
thing.
A
B
Yes,
you
could
yes.
So
oh
yeah,
that's
that's!
That's
the
that's
the
point,
so
you
know,
given
that
I
was
able
to
write
this
without
with
with
just
pure
existing
an
api.
This
means
that
there
is
no
question
and
this
addresses
your
concern
where
we
left
off
last
time.
C
B
This
topic
came
up
as
to
whether
this
can
be
done
in
other
engines.
Well,
it
can
be
as
long
as
you
can
create
functions,
create
strings,
define
properties,
retrieve
undefined
and
run
a
script.
So,
yes,
it
can
be
done
in
any
engine
by
by
this
approach,
and
if,
if
that
engine
has
has
support,
then
all
the
better
and
then
you
don't
need
to
use
this
approach.
So
so
that's
that's
one
thing:
it
is
universal,
but
of
course,
because
it
doesn't
require
engine
support,
it
may
or
may
not
be
needed
in
core.
A
B
C
B
So
that's
another
problem
and
without
engine
support
we
also
have
to
provide
the
the
what
the
data
call
it
brand
checking
ourselves.
So
so
a
v8
gives
us
a
brand
check
for
for
all
for
all
classes
that
we
generate.
You
know
from
function,
templates
and
so
forth,
so
so
basically
v8
ensures
that
an
instance
that
is
being
passed
to
the
native
side
as
the
javascript.
B
This
is,
in
fact
an
instance
of
the
class,
and
it
performs
a
check
that
it's
stronger
than
just
javascript
instance
of
so
that
so
that
way
on
the
native
side,
you
do
not
have
the
risk
of
of
miscasting
the
the
the
object
that
you
unwrap
so
so
that
check
can
be
performed.
Now
that
we
have
type
tags.
So
we
can.
B
We
can
tag
every
every
instance
that
we
create
in
this
in,
like
you
know,
when
we
use
this
javascript
snippet
approach,
so
we
can
sort
of
emulate
what
we
get
from
v8
for
for
plane
classes,
but
that
is
in
itself
an
additional
expense.
So
so
yeah
it's
it's
it's
tough
to
justify,
but
we
have
no
better
approach
right
now.
The
the
other.
The
other
aspect
of
this
is
that
tuned
from
from
v8.
B
He
did
sort
of
seem
kind
of
supportive
of
the
idea
of
adding
a
v8
api
for
this,
but
the
discussion
just
kind
of
trailed
off
there
and
I'm
not
even
sure,
if
he's
still
working
on
v8
or
not,
and
so
I
left
him
a
comment
on
the
on
the
issue
where
we
perennially
discussed
this-
and
I
haven't
received
an
answer.
So
that's
that's
basically
where
it's
at.
A
B
That's
right!
Yes,
yes,
so
there
is
one.
There
is
yet
another
aspect
of
this,
which
is
that
we
could
provide
limited
functionality
in
core
which
is
not
to
be
able
to
subclass
just
any
old
class,
but
only
the
ones
created
with
an
api.
But
even
that
is
not
super
easy,
because
I
I
looked
into
it
and
and
function
templates
are
not
values.
They're,
not
v8,
values
right,
so
so
the
function
template
that
one
creates.
B
I
I'd
have
to
double
check
if
you
can
store
it
as
a
persistent
reference,
but
but
basically
what
we
would
do
if
we,
if
we
chose
this
path,
is
to
store
the
function
template
in
a
in
a
private
property
under
constructor,
and
so
when
the
constructor
comes
back
in
in
nappy
defined
subclass,
then
that
particular
constructor
would
have
would
have
the
function
template
attached,
and
so
we
could
perform
the
inheritance
at
that
point,
and
so
so
that
would
would
would
require
support
from
the
engine
and
it
would
also
give
add-on
maintainers
the
ability
to
implement
class
hierarchies.
B
D
Yeah,
I
just
wanted
to
bring
up
how
you
mentioned.
It
wouldn't
benefit
with
like
event
targets
and
things
like
that,
because
I
feel,
like
that's
one
of
the
main
things
that
people
are
asking
for,
at
least
from
what
I've
seen
is
like.
I
want
to
pass
in
nodes
event,
emitter
constructor
to
my
node
add-on
api
in
order
to
inherit
from
it.
D
B
Yeah
and-
and
the
thing
is
even
if
even
if
we
implemented
like
a
native
version
of
event,
emitter
and
event
target
in
in
node
right
and
then
we
expose
the
specialized
api
that
that
you
know
only
deals
with
event
target
like,
for
example,
if
we
had
like
nappy
derived
from
event
target.
Let's
say
we
had
an
api
like
that,
where
internally
the
implementation
of
that
api
used
some
node
native
implementation
of
an
event
target
that
would
still
not
work,
because
currently
the
the
node
implementation
of
event
target
is
pure
js.
B
So
you
would
have
to
move
that
implementation
to
to
v8
in
order
to
or
to
the
native
side,
in
order
for
for
that
to
even
be
possible
right,
because
node
itself
cannot
retrieve
the
function
template
either
right
because
it
just
doesn't
have
support
from
the
engine.
So
so
there's
there's
so.
There's
problems
like
that
right
now,.
A
B
A
B
Right
yeah,
then
we
can
move
it
into
core
yeah.
That's
that's!
That's
pretty
much
the
only
thing
all
right!
Okay,
so
I
guess
I
guess
we
can.
We
can
decide
what
to
do
with
this
pr
it.
It
need
not
land
in
core.
I
was.
I
was
prepared
to
not
have
it
land
in
core,
but
at
least
we
got
some
really
good
reviews
there,
and
and
actually
it
exposed
a
lot
of
other
things.
So
I
wrote
like
five
different
pr's
just
to
support
this
one
and
all
of
those
are
our
landing.
B
Yeah
yeah
the
the
code
cleanup,
the
code
cleanup
came
about
because
because
I
I
need
to
do
the
type
tagging
and-
and
so
I
realized
that,
if
I'm
going
to
do
the
type
tagging
in
core
I
might
as
well,
you
know
do
it
in
the
callback
wrapper
instead
of
having
like
one
instead
of
having
javascript
calling
to
v8
calling
to
an
api
and
then
an
api
performs
a
type
check
and
calls
into
an
api
again
right.
So
so
you
know,
that's
that's
why
I
did
that.
B
But
but
if
this
is
going
to
be
outside,
then
obviously
I
can't
do
the
type
tagging
in
core.
So
I'll
probably
just
write
it
in
such
a
way
that
that
you
have
like
one,
an
api
callback
calling
another
an
api
callback,
because
it
should
be
pretty.
It
should
be
pretty
simple,
because
you
know
it's.
It's
basically
just
a
wrapper
around
an
api
callback,
but
not
such
a
wrapper
that
it
goes
back
into
javascript
and
back
into
native
again.
So
that
part
should
not
be
that
super
expensive,
but
anyway
that
was
it.
B
I
have
to
go
okay.
Thank
you
for
listening
and
thank
you
for
your
advice.
Thanks
talk
to
y'all
later,
oh
and
next
week
is
next
week
is
thanksgiving
around
here.
So
I
think
I
will
be
absent
next.
A
A
A
I
I
think
the
next
topic
that
we
wanted
to
get
into
was
the
reason
marcus
is
here
right,
yeah.
I
I
assume
so
I'll
pull
up
and
share
that
one
just
to
give
people
some
context
and
you
can
you
can
take
it
away
from
there.
E
Okay,
yeah
just
all
started
last
week
I
already
talked
to
gabriel
and
he
already
reviewed
the
my
pull
request.
It's
number
804
and
this
all
started
about
when
I
tried
to
use
naip
and
I'm
using
nappy
for
a
whole
electron,
js
application.
E
I
come
over
some
some
issues
with
even
with
the
c
plus
plus
wrapper.
That
started
usually
started
with
the
discussion
in
issue
two
three
one
which
is
close
already,
which
was
about
the
shortcomings
about
async
worker
because,
for
example,
async
request
callback
base
and
I
like
promises.
Of
course,
I
could
also
use
it
for
qr
routines
in
javascript,
and
it
was
also
that
I
didn't
want
to
use
the
worker
threads
out
of
node
because
I
don't
know
their
context.
I
don't
know
how
much
are
there.
E
E
I
just
want
a
small,
a
very
lean,
copic
interface
and
also
I
experienced
some
shortcomings
about
async
worker,
and
so
I
wrote
two
wrapper
classes
that
are
only
which
are
just
built
around
threads
for
let's
say
function,
and
I
use
them
in
my
production
code,
which
is
already
out
in
the
field,
and
it
was
just
about
hey
with
some
some
more
unit
tests.
I
can
just
make
a
pull
request
for
for
nappy,
so
everybody
could
use
it.
So
I
just
get
rid
of
some
simple
plus
17
things
and
yeah.
E
Then
this
whole
thing
worked.
It's
basically
just
that
it
follows
the
pattern
that
usually
you
have
functions
in
c
plus,
and
then
you
have
just
only
a
free
task.
You
have
the
task
of
converting
the
javascript
parameters
into
c
plus
ones,
then
somehow
schedule
the
task
to
return
something
and
to
do
something
somewhere
in
your
code.
E
And
after
that
you
want
to
have
a
function
which
gets
a
sct
future,
which
then
looks
okay,
it's
an
exception.
You
already
running
again
in
the
in
the
nrp
background.
So
if
you
encounter
exception
stored
there,
it
will
throw
the
exception
in
javascript
or
you
can
catch
it
and
then
you
just
convert
it
and
then
you
will
fulfill
or
error
your
promise,
and
this
is
done
with
just
one
simple
lines.
Maybe
like
you
should
share
my
screen
or
you
could
also.
E
E
Now
it
wants
me
to
reopen
if
I
just
rejoin
or
it's
it's
really.
If,
if
you
look
at
the,
if
you.
A
F
E
This
is
basically
everything
you
want
to
do
in
your
c
plus
plus
code,
so
the
yeah
for
for
this
example,
you
have
the
jsfrontingnative
function
and
this
function
will
return
a
promise
which
will
be
fulfilled
in
some
day
in
the
future
when
the
native
code
for
first
calls
the
scd
function
later,
of
course,
callback
infos
for
the
javascript
parameters
and
then
the
new
class
one
of
the
one
two
new
classes,
as
the
generic
wrapper,
which
I
am
giving
a
template,
parameter
value
type,
which
can
be
anything
of
your
desire
from
a
double
you
ins
or
your
own
struct.
E
E
So
it
already
knows
how
to
convert
the
data
back
to
javascript,
which
you
want
to
return
later
and
then
in
the
next
stars.
You
can
just
see
that
I
want
in
just
a
number,
expect
the
number
as
a
parameter
in
from
javascript,
and
then
I
give
this.
The
native
function
start
test,
which
also
gets
this
sad
function,
which
it
can
call
at
any
time
to
yeah.
When
it's
done
and
the
good
thing
is.
I
followed
the
right
pattern.
The
resource
allocation
is
initialization
pattern
by
shared
from
this.
E
So
as
long
as
the
std
function,
object
is
not
destroyed,
which
you
need
to
fulfill
it.
Then
the
lifetime
is
also
handled
correctly,
so
that,
if,
if
nobody
is,
is
calling
the
sd
function
because
they
destroyed
it,
then
of
course
the
whole
thing
will
be
destructed,
and
otherwise
I
don't
have
to
care
much.
I
will
just
handle
this
sad
function
somewhere.
Usually,
I
could
also
put
it
into
a
boost
post,
for
example,
or
boost
detach,
and
then
some
other
thread
can
just
call
this
sad
function
and
can
store
also
an
exception
in
this
future.
E
No
definitely
a
generic
wrapper
class.
Yet
this
one
cc,
okay,
you
can
see
it
right
here.
It's
just.
We
have
this,
also
a
simple
z
plus
function.
E
We
have
a
conversion
function
that
could
also
be
a
lambda
of
course,
and
here
we
can
see
also
where
this
would
be
in
action.
Also,
only
the
star
task
is
where
I
for,
for
demonstration
purposes,
start
a
sct
threat,
but
usually
I
could
also
just
put
it
in,
like
example,
with
boost
asia
again
and
then,
if
you
go
further
down
you
can
see
in
in
javascript,
then
it's
it's
very
easy
because
then
you
just
wait
on
this
function.
Of
course,.
A
E
And
the
thing
is,
I
also
thought
that
usually
it's
just
for
for
me
that
I
give
in
I
just
want
to
call
a
c
plus
plus
function
and
a
procedural
way.
So
I
give
you
data
get
paid
data
out
and
this
will
be
fulfilled
some
some
time
but,
for
example,
also
the
use
case
where
I
have
to
pull
a
state
of
an
usb
device
very
frequently
and
want
to
update
my
ui
with
50
milliseconds
intervals,
for
example,
and
then
I
assumed
that
this
whole
destruction
and
destruction
in
timer
thing
would
get
ugly.
E
A
E
Yeah,
it's
it's.
The
the
the
threat
will
be
detached
so
because
we
don't
have
to
manage
lifetimes
anymore,
because
we
put
one
of
the
we
put.
The
std
function,
the
native
callback
into
the
task.
E
They've
put
around
as
a
fretsafe
function
with
to
to
do
the
whole
lifetime
things
of
the
native
and
javascript
code,
and
also
to
streamline
the
use
case
of
converts.
Your
your
things
also
make
exception
usage
easier
because
then
you
see
it
just
gets
an
sd
function
as
it
future
with
this
type.
A
Course,
okay,
I
think
that's
the
I'll
have
to
I'll
spend
a
little
bit
more
time
to
take
a
look
at
it
this
afternoon.
Anybody
else
have
any
other
questions.
G
E
E
It
seems
that
that
it's
broke
on
some
other
requests
too.
G
C
C
E
A
But
it
definitely
seems
like
it
sounds
from
the
code.
It
looks
like
an
easier
way
to
use
the
thread,
save
functions
so.
E
Or
I
even
did
a
youtube
talk
about
this
whole
combination
with
electron.js.
If
somebody
wants
to
watch
it.
A
Do
you
did
you
add
the
link
to
the
conversation?
Okay.
A
Okay,
here
I'll
just
post
that
on
your
pr,
just
as
a
as
as
a
video
which,
which
talks
more
about
this
just
for
reference
because
it'll
be
that
that'll
be
people
can
find
the
questions
or
anything.
A
Okay
sounds
good
yeah.
Well,
thanks,
thanks
for
coming,
we'll
move
on
to
the
other
issues
well
feel
welcome
to
stick
around
for
the
rest
of
the
discussion.
Thank
you.
So,
let's
move
to
our
regular
agenda,
which
is
looking
at
what's
tagged
for
the
milestones
oops
I
gotta
get
to
the
right.
A
A
Okay,
so
what
we
have
tagged
review
external
examples,
I
don't
think
we've
had
a
chance
to
get
to
that.
Yet
yet
tracking
issues
for
new
modules
that
have
been
ported
over,
I
don't
think,
doesn't
look
like
there's
anything
new
since
last
week.
On
that
front,
we
can
look
at
npm.
A
A
E
H
Yeah
so
yeah,
just
to
what
I
understood
is
that
he
need
the
pr.
H
832
and
because
he
has
some
tests
that
failed
because
of
that
right.
So
when
we
land
this
he
can.
H
Yeah
yeah
very
base
and
yeah
and
go
forward
yeah.
Okay,.
C
A
E
A
E
A
A
A
A
A
A
A
A
A
A
A
A
Front
so
this
one,
I
think
this
is
the
one
of
the
this
was
the
one
that
gabriel
already
mentioned
in
terms
of
cleaning
up
some
binding
this
one.
I
think.
A
A
A
I
guess
we
got
the
the
blog
post
out,
which
was
great
thanks
for
everybody's
help
in
putting
that
together,
but
that's
all
I'd
have
if
anybody
else
have
anything
else.
A
Okay,
well,
if
not
thanks
to
everybody
who
took
the
time
to
join
thanks
marcus
for
coming,
if
you're
interested
in
you
know,
participating
ongoing
certainly
feel
free
to
join
our
meetings
and
we
hope
to
see
you
around
in
github.