3 ms·

In my opinion, this is a flawed proposal. The disposer should not be a method on the object, because it means it cannot pass around the resource without the ris

In my opinion, this is a flawed proposal. The disposer should not be a method on the object, because it means it cannot pass around the resource without the risk that the recipient of the resource disposes it themselves. A safer alternative is available- [item, disposer]. See this issue: https://github.com/tc39/proposal-explicit-resource-management/issues/160 https://github.com/tc39/proposal-explicit-resource-managemen...

hn_throwaway_99 3y ago
Meh, I don't think the more confusing interface defined in that issue warrants the added complexity. using should only be used for local variables, and the example you give is fundamentally complicated by who should be responsible for disposing of the object: function inner(defaultResource) { const resource = defaultResource ?? getResource(); using resource; } That is, if a defaultResource is passed in, the caller should be responsible for disposing it, while if it wasn't passed in, the inner function should be responsible for disposing it. IMO cases like this are better handled with linting rules that forbid use of using on anything but an object directly returned by a function on that line.
deleted 3y ago
[deleted]
lolinder 3y ago
In another language I think your proposal could be quite reasonable, but it requires using patterns that aren't common in JavaScript, which would complicate the language more than the alternate proposal. The biggest problem I see is that to use the feature in a class you'd be forced to define a static factory method to produce the object-disposer tuple. To be effective, a static factory needs to be paired with a private constructor, but JS has no first-class support for those, which means you have to go to contortions with exceptions to make sure people don't accidentally instantiate a non-disposable instance of the class. The existing proposal uses a well-establish way to interact with language features—the well-known symbol [0]. It's compatible with any way of defining an object, and doesn't require using any particular pattern that may be unnatural for a subset of the community. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol#well-known_symbols https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- rbalicki 3y ago
  Yes, the requirement that static constructors are used makes this substantially less ergonomic than it would otherwise be for the reasons you point out. Some of the React hooks in Isograph use this pattern, and as a result the constructor returns an instance in an invalid state: https://github.com/isographlabs/isograph/blob/1a8182355ac9d121318213d1d8591480d5c1da12/libs/isograph-react-disposable-state/src/CacheItem.ts#L69 https://github.com/isographlabs/isograph/blob/1a8182355ac9d1... I'm of the opinion that this is a paper cut worth stomaching in favor of the addition of an idiom that provides genuine safety. The type for the class and the static conductor (ie a free function) could be exposed, but the class itself could be hidden.

hn_throwaway_99 3y ago

Meh, I don't think the more confusing interface defined in that issue warrants the added complexity. using should only be used for local variables, and the example you give is fundamentally complicated by who should be responsible for disposing of the object: function inner(defaultResource) { const resource = defaultResource ?? getResource(); using resource; } That is, if a defaultResource is passed in, the caller should be responsible for disposing it, while if it wasn't passed in, the inner function should be responsible for disposing it. IMO cases like this are better handled with linting rules that forbid use of using on anything but an object directly returned by a function on that line.

deleted 3y ago

[deleted]

lolinder 3y ago

In another language I think your proposal could be quite reasonable, but it requires using patterns that aren't common in JavaScript, which would complicate the language more than the alternate proposal. The biggest problem I see is that to use the feature in a class you'd be forced to define a static factory method to produce the object-disposer tuple. To be effective, a static factory needs to be paired with a private constructor, but JS has no first-class support for those, which means you have to go to contortions with exceptions to make sure people don't accidentally instantiate a non-disposable instance of the class. The existing proposal uses a well-establish way to interact with language features—the well-known symbol [0]. It's compatible with any way of defining an object, and doesn't require using any particular pattern that may be unnatural for a subset of the community. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol#well-known_symbols https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

rbalicki 3y ago
Yes, the requirement that static constructors are used makes this substantially less ergonomic than it would otherwise be for the reasons you point out. Some of the React hooks in Isograph use this pattern, and as a result the constructor returns an instance in an invalid state: https://github.com/isographlabs/isograph/blob/1a8182355ac9d121318213d1d8591480d5c1da12/libs/isograph-react-disposable-state/src/CacheItem.ts#L69 https://github.com/isographlabs/isograph/blob/1a8182355ac9d1... I'm of the opinion that this is a paper cut worth stomaching in favor of the addition of an idiom that provides genuine safety. The type for the class and the static conductor (ie a free function) could be exposed, but the class itself could be hidden.