3 ms·

JavaScript development looks really strange. const resource = { [Symbol.dispose]: () => { console.log("Hooray!"); }, }; Why not just cons

JavaScript development looks really strange. const resource = { [Symbol.dispose]: () => { console.log("Hooray!"); }, }; Why not just const resource = { dispose() { console.log("Hooray!"); }, }; Why introduce this weird Symbol stuff?

junon 3y ago
Backwards compatibility. This can't conflict with existing types that have `dispose` on them already. Symbols are private, meaning two symbols with the same name are not the same symbol. Symbols use object reference equality, not value equality. So `Symbol.dispose` is the only way to refer to the dispose method they're looking for, without conflicting with any existing fields called "dispose".
deleted 3y ago
[deleted]
manojlds 3y ago
> Symbol is a built-in object whose constructor returns a symbol primitive — also called a Symbol value or just a Symbol — that's guaranteed to be unique. Symbols are often used to add unique property keys to an object that won't collide with keys any other code might add to the object, and which are hidden from any mechanisms other code will typically use to access the object. That enables a form of weak encapsulation, or a weak form of information hiding. > Prior to well-known Symbols, JavaScript used normal properties to implement certain built-in operations. For example, the JSON.stringify function will attempt to call each object's toJSON() method, and the String function will call the object's toString() and valueOf() methods. However, as more operations are added to the language, designating each operation a "magic property" can break backward compatibility and make the language's behavior harder to reason with. Well-known Symbols allow the customizations to be "invisible" from normal code, which typically only read string properties. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Essentially if they use dispose() like you mention, what happens if someone already has code that has dispose? And in future, avoid people accidentally calling these.
- vbezhenar 3y ago
  Using `using` is opt-in. So if you have code that has dispose function used for other purposes, rewrite that code before using `using`.
  - manojlds 3y ago
    That's case for this particular feature, but the approach has been with know symbols and is how they introduce new features into the app. Also, you are assuming the consumer of a class is same as someone that used / uses the class. What if the library author has dispose and someone wrongly use using with it?
  - MrJohz 3y ago
    Kind of the other way round. If you have code that has a function named `dispose`, it will keep on working just fine, nothing needs to be renamed (not now, and not in the future when you want to start using `using`). The symbol `Symbol.dispose` is special, unlike any normal string or identifier, because it didn't exist until the new standard, so existing code can't have been using it. This guarantees a level of backwards compatibility that wouldn't exist otherwise.
  - deleted 3y ago
    [deleted]
  - chrisco255 3y ago
    This would break many sites on the web, if they roll this out as a native feature of JS. Importantly, JS generally cannot break backwards compatibility.
zirror 3y ago
My guess is backwards compatibility. There might be applications out there that have a dispose method for different reasons. Symbol.dispose is literally impossible to be already in use, since symbols are guaranteed to be unique.
cbzoiav 3y ago
I'd imagine dispose is a common function name and being dynamically typed there is potentially a lot of code out there that already has a "call dispose if it exists on this object" pattern. Vs this won't break anything existing.
saiojd 3y ago
Imagine that resource inherits from a class with an existing method called dispose. What happens then?
- deleted 3y ago
  [deleted]
progx 3y ago
And how you or JavaScript know that dispose is an automatically called function?
masklinn 3y ago
> Why introduce this weird Symbol stuff? Because this potentially break every existing object with a `dispose` symbol. That is exactly why symbols were added in ES6, and what they're used for. You're just 8 years later.
linkgoron 3y ago
Symbols are used for all kinds of "built in" functions, and they were not "introduced" for this feature. As symbols are unique, they don't break/interfere with existing methods/properties. Therefore, if someone already has a dispose function named dispose, the new feature won't interfere with a method called dispose method and vice-versa. "Well-known" symbols include things like Symbol.iterator that make "for...of" loops possible, Symbol.asyncIterator for async for loops, Symbol.hasInstance for instanceOf, Symbol.toStringTag for toString, and others.

junon 3y ago

Backwards compatibility. This can't conflict with existing types that have `dispose` on them already. Symbols are private, meaning two symbols with the same name are not the same symbol. Symbols use object reference equality, not value equality. So `Symbol.dispose` is the only way to refer to the dispose method they're looking for, without conflicting with any existing fields called "dispose".

deleted 3y ago

[deleted]

manojlds 3y ago

> Symbol is a built-in object whose constructor returns a symbol primitive — also called a Symbol value or just a Symbol — that's guaranteed to be unique. Symbols are often used to add unique property keys to an object that won't collide with keys any other code might add to the object, and which are hidden from any mechanisms other code will typically use to access the object. That enables a form of weak encapsulation, or a weak form of information hiding. > Prior to well-known Symbols, JavaScript used normal properties to implement certain built-in operations. For example, the JSON.stringify function will attempt to call each object's toJSON() method, and the String function will call the object's toString() and valueOf() methods. However, as more operations are added to the language, designating each operation a "magic property" can break backward compatibility and make the language's behavior harder to reason with. Well-known Symbols allow the customizations to be "invisible" from normal code, which typically only read string properties. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Essentially if they use dispose() like you mention, what happens if someone already has code that has dispose? And in future, avoid people accidentally calling these.

vbezhenar 3y ago
Using `using` is opt-in. So if you have code that has dispose function used for other purposes, rewrite that code before using `using`.
- manojlds 3y ago
  That's case for this particular feature, but the approach has been with know symbols and is how they introduce new features into the app. Also, you are assuming the consumer of a class is same as someone that used / uses the class. What if the library author has dispose and someone wrongly use using with it?
- MrJohz 3y ago
  Kind of the other way round. If you have code that has a function named `dispose`, it will keep on working just fine, nothing needs to be renamed (not now, and not in the future when you want to start using `using`). The symbol `Symbol.dispose` is special, unlike any normal string or identifier, because it didn't exist until the new standard, so existing code can't have been using it. This guarantees a level of backwards compatibility that wouldn't exist otherwise.
- deleted 3y ago
  [deleted]
- chrisco255 3y ago
  This would break many sites on the web, if they roll this out as a native feature of JS. Importantly, JS generally cannot break backwards compatibility.

zirror 3y ago

My guess is backwards compatibility. There might be applications out there that have a dispose method for different reasons. Symbol.dispose is literally impossible to be already in use, since symbols are guaranteed to be unique.

cbzoiav 3y ago

I'd imagine dispose is a common function name and being dynamically typed there is potentially a lot of code out there that already has a "call dispose if it exists on this object" pattern. Vs this won't break anything existing.

saiojd 3y ago

Imagine that resource inherits from a class with an existing method called dispose. What happens then?

deleted 3y ago
[deleted]

progx 3y ago

And how you or JavaScript know that dispose is an automatically called function?

masklinn 3y ago

> Why introduce this weird Symbol stuff? Because this potentially break every existing object with a `dispose` symbol. That is exactly why symbols were added in ES6, and what they're used for. You're just 8 years later.

linkgoron 3y ago

Symbols are used for all kinds of "built in" functions, and they were not "introduced" for this feature. As symbols are unique, they don't break/interfere with existing methods/properties. Therefore, if someone already has a dispose function named dispose, the new feature won't interfere with a method called dispose method and vice-versa. "Well-known" symbols include things like Symbol.iterator that make "for...of" loops possible, Symbol.asyncIterator for async for loops, Symbol.hasInstance for instanceOf, Symbol.toStringTag for toString, and others.