Remove "standalone" resource method from Deno namespace

[kitsonk]

Methods like Deno.read() and Deno.write() are effectively redundant as there are other better objects to manage the resources (like Deno.File) and having to deal explicitly with the rid which is just a number can be confusing and error prone to users.

[caspervonb]

Methods like Deno.read() and Deno.write() are effectively redundant as there are other better objects to manage the resources (like Deno.File) and having to deal explicitly with the rid which is just a number can be confusing and error prone to users.

I'm in favour but note that that this will completely break std/wasi, that's okay but I'll have to rewrite it.

[bartlomieju]

Deno.seek() and Deno.seekSync() should be removed as well.

[bartlomieju]

More methods that should be moved to Deno.File class:

• Deno.fsyncSync
• Deno.fsync
• Deno.fdatasyncSync
• Data.fdatasync
• Deno.flock
• Deno.flockSync
• Deno.funlock
• Deno.funlockSync

CC @caspervonb

[caspervonb]

More methods that should be moved to Deno.File class:

• Deno.fsyncSync
• Deno.fsync
• Deno.fdatasyncSync
• Data.fdatasync
• Deno.flock
• Deno.flockSync
• Deno.funlock
• Deno.funlockSync

CC @caspervonb

SGTM, patches coming right up.

[wojpawlik]

Should Deno.close be deprecated in favor of Deno.File::close?

[bartlomieju]

Should Deno.close be deprecated in favor of Deno.File::close?

It's still debated, but most likely it won't be deprecated.

[caspervonb]

Should Deno.close be deprecated in favor of Deno.File::close?

It's still debated, but most likely it won't be deprecated.

I think we should, in favour of using explicit resource management (https://github.com/tc39/proposal-explicit-resource-management stage 2) and finalisers.

Isn't the point of removing these to get rid of isomorphic resources internally?

[bartlomieju]

Should Deno.close be deprecated in favor of Deno.File::close?

It's still debated, but most likely it won't be deprecated.

I think we should, in favour of using explicit resource management (https://github.com/tc39/proposal-explicit-resource-management stage 2) and finalisers.

Isn't the point of removing these to get rid of isomorphic resources internally?

It's a good point and that proposal looks interesting. Ideally we should eyeball adding automatic cleanup for all resources using FinalizationRegistry. I'm not sure though, if we could deliver on that for 2.0.

[piscisaureus]

I don't see the point of removing these methods at this time - it just breaks user code unnecessarily.
We should have a discussion on how to proceed with automatic resource cleanup first.

[bartlomieju]

This is now done as of #25213 and Deno 2.0.0-rc.0.