@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();