Remove pure JS (non native) io functions from Deno namespace

Question

Remove pure JS (non native) io functions from Deno namespace

lucacasonato opened this issue 3 years ago · comments

Luca Casonato commented 3 years ago

I propose we remove the following APIs from the Deno namespace, and move them to std:

Types:

Functions:

Timeline

I suggest we mark all the APIs we want to remove with @deprecated, and add a deno lint diagnostic for when these APIs are used. In Deno 2.0 we can then remove these APIs.

Reasoning

Code which does not actually require native syscalls should not use Deno namespace APIs as this makes the code incompatible with browsers, even though there is no need for that to be the case. An example of this: https://deno.land/std@0.90.0/io/streams.ts. This uses Deno APIs, even though no native calls are preformed, making this code unusable in a web browser for no good reason.

Kitson Kelly · Answer 1 · Tue Mar 16 2021 05:43:46 GMT+0800 (China Standard Time)

Why move the types? They are referred to by other built ins that are returned, are they not?

Kitson Kelly · Answer 2 · Tue Mar 16 2021 05:45:32 GMT+0800 (China Standard Time)

Buffer is also mentioned in #9588, we should maybe close that?

Luca Casonato · Answer 3 · Tue Mar 16 2021 05:52:29 GMT+0800 (China Standard Time)

Why move the types?

Same reason as to move the functions. Code using Reader / Writer etc does not work when lib is dom instead of deno.ns. IMO if it doesnt need to be a binding (or a type for those bindings) because it can work just fine in the browser, it should not be part of the Deno namespace.

They are referred to by other built ins that are returned, are they not?

The builtins never explicitly return or take a reader/writer after these changes as far as i'm aware. They only return types that implement Reader or Writer. Instead of using implement in the d.ts, we can just specify the read / write methods no the interfaces directly. This would make them implicitly implement Reader / Writer (just like interfaces work in Go).

Tim Reichen · Answer 4 · Mon Apr 26 2021 22:11:28 GMT+0800 (China Standard Time)

@lucacasonato in addition to that: would you be open to rename
Deno.iter -> Deno.iterator
Deno.iterSync -> Deno.iteratorSync
for aligning with the js name like in Symbol.iterator?

Luca Casonato · Answer 5 · Mon Apr 26 2021 22:19:24 GMT+0800 (China Standard Time)

No. They are both in the process of being deprecated and will be removed. No reason to rename.

Ryan Dahl · Answer 6 · Tue Jul 06 2021 06:07:48 GMT+0800 (China Standard Time)

I'm in agreement. It's very painful to let web streams (ReadableStream/WritableStream) win over go streams (Reader/Writer). Go streams is plainly more general and vastly simpler. But we must have web streams because of fetch. And having two different and incompatible stream abstractions is worse than having one shitty one.

One of the original intentions of Deno was to correct the abysmal streams implementation in Node. I think Go provides a very elegant and complete solution with a beautiful library of combinations.

Skye · Answer 7 · Tue Jul 06 2021 06:22:37 GMT+0800 (China Standard Time)

We just have to hope that there will be a webstream2 at some point in the future that is based on go streams :/

Nayeem Rahman · Answer 8 · Tue Jul 06 2021 09:17:19 GMT+0800 (China Standard Time)

Just to clarify, this issue was about a purely symbolic refactor to remove the explicit type definitions of Reader and Writer in favour of just defining the read() and write() methods on their implementers. This is logical because there are no stable built-ins that accept these interfaces, only ones that return them. A one sided protocol so to speak. Since they do have consumers in std, it would be more appropriate to have the definitions there.

Why @ry mentions above is the result of more recent discussion to remove even the concrete read() and write() methods in favour of web stream APIs. We should continue in #11018 for that.

Yoshiya Hinosawa · Answer 9 · Thu Dec 22 2022 15:58:55 GMT+0800 (China Standard Time)

We're removing the usages of Deno.Reader, Deno.Writer, ... from std in denoland/deno_std#3030

Asher Gomez · Answer 10 · Fri Aug 25 2023 08:28:27 GMT+0800 (China Standard Time)

Types:

Deno.Reader

Deno.Writer

Deno.ReaderSync

Deno.WriterSync

Deno.Closer

Perhaps, 2.0 is a good time to deprecate these interfaces. A counterargument is fast streams implementations are still in progress, and I wouldn't expect people to be happy with the deprecation unless the performance of the alternative was on par or better.

Yoshiya Hinosawa · Answer 11 · Fri Aug 25 2023 17:44:02 GMT+0800 (China Standard Time)

What to do about Deno.Seeker and Deno.SeekerSync?

Yoshiya Hinosawa · Answer 12 · Wed Sep 13 2023 16:41:57 GMT+0800 (China Standard Time)

There seem a few concerning points to this move:

There seem no alternative way to support synchronous I/O using ReadableStream based APIs.
The support of seek behavior will be awkward though it's still possible to perform with mixed usage of ReadableStream and existing seek() method

Yoshiya Hinosawa · Answer 13 · Thu Sep 14 2023 17:32:11 GMT+0800 (China Standard Time)

sync behavior might be implemented as FileSystemSyncAccessHandle in the future

seek is available in FileSystemWritableFileStream, but I couldn't find a way to seek during reading in Web APIs

Asher Gomez · Answer 14 · Thu Dec 28 2023 11:42:42 GMT+0800 (China Standard Time)

Update: std/log no longer depends on Deno.Writer. See: denoland/deno_std#4021

Asher Gomez · Answer 15 · Mon Jan 29 2024 14:52:47 GMT+0800 (China Standard Time)

What to do about Deno.Seeker and Deno.SeekerSync?

What do we think about this? Best to come to a decision before Deno v2. Related: Deno.seek() and Deno.seekSync() were deprecated in Deno 1.40.