7 ms·

Private brand checks a.k.a. `#foo in obj`

14 points by feross 6y ago

jwalton 6y ago
Now you can create an API where it’s not enough to pass in an object that has all the properties the API requires, it has to have some special inscrutable magic that you can’t programmatically observe. I can only imagine the sort of confusion and horror an API that relies on this would generate in novice developers.
- notriddle 6y ago
  You can polyfill this using https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... -- you "brand" your objects by stashing references to them in WeakMaps, and hide the WeakMap using a closure.
- kjeetgill 6y ago
  Only sorta! From the article: > Since private names are only available inside the class which defines them, the test must also occur inside the class So code in other classes can't introduce dependance on this atleast. It's not any pickier than checking the class of an object, but only within the class itself. It's a narrower footgun that I'd first considered it to be.
dgreensp 6y ago
I guess you still need that try-catch for back compat, though? Also note the bulk of the article is about edge cases that are unlikely to occur in practice. It helped me understand what they were talking about when I realized this. You aren’t actually going to inherit a private field through the prototype chain or deal with partially-initialized objects, in all likelihood. Personally, as a TypeScript fan, my class-oriented code uses the “protected” keyword a lot, and it suits my purposes well. I don’t need runtime “safety,” and I find that truly private fields to one class (not subclasses or tests, for example) have limited use.
- inbx0 6y ago
  What platform are you targeting that supports private class fields but does not support (in a month or two I guess) the new #foo in obj syntax?
Toutouxc 6y ago
At this point I'm not sure whether I don't know how to use this because I don't write JavaScript, or I don't write JavaScript because of stuff like this. In all seriousness, this looks like a massive footgun and feels to me like something you wouldn't want to use in what's essentially a duck-typed language. Or is there something this Ruby lover is missing?
- jmull 6y ago
  I think the post is making this seem more complicated than it is. (Not a criticism of the post -- it's interesting to explore edge cases sometimes.) The general takeaway is private fields are private, and the "in" operator is consistent with that. If constructor code results in an incorrectly constructed object, that's simply a bug in the constructor code, not really anything specifically to do with fields, private fields, in operator, etc. (I guess this is a criticism of the post. Bringing this up implies it's somehow relevant to the topic, but it isn't and causes confusion.)
legerdemain 6y ago
Naïve question: has JS evolved into distinctive dialects based on area of application? To a relative outsider, it feels like "V8 JavaScript" and "in-browser JavaScript" are heading in different directions.
- inbx0 6y ago
  Given that Chromium dominates the browser market, where does "V8 JavaScript" end and "in-browser JavaScript" begin?
  - legerdemain 6y ago
    Very well, replace "V8 JavaScript" with "Node JavaScript."
krossitalk 6y ago
This wasn't necessary as a syntax addition before Class keywords. Doing JS the old fashioned way you would simply leave #foo inside a scope only A could access. IIFE (Immediately invoked function expressions) made a lot more sense to me than this Class restructuring. Which is all the more frustrating because it's just that, a restructuring. The JS fundamentals of scopes haven't changed.

14 points by feross 6y ago

Now you can create an API where it’s not enough to pass in an object that has all the properties the API requires, it has to have some special inscrutable magic that you can’t programmatically observe. I can only imagine the sort of confusion and horror an API that relies on this would generate in novice developers.

notriddle 6y ago
You can polyfill this using https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... -- you "brand" your objects by stashing references to them in WeakMaps, and hide the WeakMap using a closure.
kjeetgill 6y ago
Only sorta! From the article: > Since private names are only available inside the class which defines them, the test must also occur inside the class So code in other classes can't introduce dependance on this atleast. It's not any pickier than checking the class of an object, but only within the class itself. It's a narrower footgun that I'd first considered it to be.

dgreensp 6y ago

I guess you still need that try-catch for back compat, though? Also note the bulk of the article is about edge cases that are unlikely to occur in practice. It helped me understand what they were talking about when I realized this. You aren’t actually going to inherit a private field through the prototype chain or deal with partially-initialized objects, in all likelihood. Personally, as a TypeScript fan, my class-oriented code uses the “protected” keyword a lot, and it suits my purposes well. I don’t need runtime “safety,” and I find that truly private fields to one class (not subclasses or tests, for example) have limited use.

inbx0 6y ago
What platform are you targeting that supports private class fields but does not support (in a month or two I guess) the new #foo in obj syntax?

Toutouxc 6y ago

At this point I'm not sure whether I don't know how to use this because I don't write JavaScript, or I don't write JavaScript because of stuff like this. In all seriousness, this looks like a massive footgun and feels to me like something you wouldn't want to use in what's essentially a duck-typed language. Or is there something this Ruby lover is missing?

jmull 6y ago
I think the post is making this seem more complicated than it is. (Not a criticism of the post -- it's interesting to explore edge cases sometimes.) The general takeaway is private fields are private, and the "in" operator is consistent with that. If constructor code results in an incorrectly constructed object, that's simply a bug in the constructor code, not really anything specifically to do with fields, private fields, in operator, etc. (I guess this is a criticism of the post. Bringing this up implies it's somehow relevant to the topic, but it isn't and causes confusion.)

legerdemain 6y ago

Naïve question: has JS evolved into distinctive dialects based on area of application? To a relative outsider, it feels like "V8 JavaScript" and "in-browser JavaScript" are heading in different directions.

inbx0 6y ago
Given that Chromium dominates the browser market, where does "V8 JavaScript" end and "in-browser JavaScript" begin?
- legerdemain 6y ago
  Very well, replace "V8 JavaScript" with "Node JavaScript."

krossitalk 6y ago

This wasn't necessary as a syntax addition before Class keywords. Doing JS the old fashioned way you would simply leave #foo inside a scope only A could access. IIFE (Immediately invoked function expressions) made a lot more sense to me than this Class restructuring. Which is all the more frustrating because it's just that, a restructuring. The JS fundamentals of scopes haven't changed.