Deno: Feature Request: Deno.Listener.rid

Created on 4 Sep 2019  路  18Comments  路  Source: denoland/deno

As per the title, it seems strange that Deno.Listener instances do not have an exposed rid property.

good first issue

Most helpful comment

For @sidntrivedi012 @lucacasonato and other new contributors, also notice that we have https://github.com/denoland/deno_std that needs quite a bit help (it is the standard modules of Deno). It is modeled after Go (and maybe a bit of Python)'s standard library (to avoid unneeded dependency problems that happened in Node), but we are still lacking a lot of features there. It would also be very cool if you want to contribute to it (deno_std is about TypeScript, in comparison to Deno core, which is the bare minimum and more involving in coding in Rust)

All 18 comments

@sidntrivedi012 this is good first issue

I'll take this one

Before I do this, should Deno.Listener even have an rid? The description of listener is "A Listener is a generic network listener for stream-oriented protocols.". This to me means it does not per se have to have an rid because it is not per se one of "open files, sockets, and other concepts". It could also be implemented by a different library in which case it does not need an rid. I might also be completely misunderstanding this. In any case the implementation of Listener, ListenerImpl already has an rid. Can someone clarify if Listener should have an rid?

Before I do this, should Deno.Listener even have an rid? The description of listener is "A Listener is a generic network listener for stream-oriented protocols.". This to me means it does not per se have to have an rid because it is not per se one of "open files, sockets, and other concepts". It could also be implemented by a different library in which case it does not need an rid. I might also be completely misunderstanding this. In any case the implementation of Listener, ListenerImpl already has an rid. Can someone clarify if Listener should have an rid?

You're right, there is rid field on ListenerImpl - it's marked as readonly so it already should be possible to get it's value by listener.rid.

So this can be closed?

There's no current way (that I can see) of accessing the rid.

https://github.com/denoland/deno/blob/master/js/net.ts#L146
The returned object is of type ListenerImpl which contains the rid, but as it's returned as a Deno.Listener in TypeScript, it can not be accessed from TS. (without using 'as any', etc.),

Am I missing something?

There's no current way (that I can see) of accessing the rid.

https://github.com/denoland/deno/blob/master/js/net.ts#L146
The returned object is of type ListenerImpl which contains the rid, but as it's returned as a Deno.Listener in TypeScript, it can not be accessed from TS. (without using 'as any', etc.),

Am I missing something?

You're also right, basically rid should be exposed on the interface like on Conn

@sidntrivedi012 this is good first issue

Hey @bartlomieju , thanks a lot for pointing this issue out. Will look into it. Thanks :).

For @sidntrivedi012 @lucacasonato and other new contributors, also notice that we have https://github.com/denoland/deno_std that needs quite a bit help (it is the standard modules of Deno). It is modeled after Go (and maybe a bit of Python)'s standard library (to avoid unneeded dependency problems that happened in Node), but we are still lacking a lot of features there. It would also be very cool if you want to contribute to it (deno_std is about TypeScript, in comparison to Deno core, which is the bare minimum and more involving in coding in Rust)

Also I agree that Deno.Listener itself should not expose rid as it is quite a general interface. We might however make ListenerImpl implement something like NetListener with rid property that extends from Deno.Listener, since I do feel that direct access to rid is probably useful

The actual rid property already exists on the object, it's just a question of the best way to expose it.

I guess the question is where is Listener used outside of ListenerImpl? Does it have a rid? Would a null rid be appropriate?

It seems logical to me that Listener would expose the ListenerImpl.rid, just as Conn exposes ConnImpl.rid - but I'm not sure of Listener's uses (or planned uses)

Confusing questions like this will _always_ arise when you have interface Thing and class ThingImpl implements Thing 馃様

For @sidntrivedi012 @lucacasonato and other new contributors, also notice that we have https://github.com/denoland/deno_std that needs quite a bit help (it is the standard modules of Deno).

Sure, since I am currently learning Javascript and planning to learn typescript as soon as possible. Thus, will jump in soon. Thanks :)

So should
1) Listener have an rid
2) ListenerImpl implement a new class NetListener which extends Listener and has an rid and listen returns NetListener
3) listen return ListenerImpl rather than Listener?
4) something else - please specify

Once I know what should happen I can implement it.

@ry @piscisaureus @kevinkassimo @bartlomieju

IMHO Listener have an rid. I can imagine someone doing:

const listener = Deno.listen(...);
...
close(listener.rid);

instead of :

const listener = Deno.listen(...);
...
listener.close();

@bartlomieju any updates to this? looks like ListenResponse interface returns rid already or I'm wrong?

interface ListenResponse { rid: number; localAddr: Addr; }

PR here https://github.com/denoland/deno/pull/5571. Let me know if this is ok? I think there was a discussion on how it should be added. I can update it if necessary.

Released in v1.1.0

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davidbarratt picture davidbarratt  路  3Comments

ry picture ry  路  3Comments

xueqingxiao picture xueqingxiao  路  3Comments

zugende picture zugende  路  3Comments

metakeule picture metakeule  路  3Comments