Private brand checks a.k.a. `#foo in obj` | Hacker News Reader

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

v8.dev

14 pointsfeross11 comments

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.

You can polyfill this using 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.

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.

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.

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?

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.)

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.

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?

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.

Given that Chromium dominates the browser market, where does "V8 JavaScript" end and "in-browser JavaScript" begin?

Very well, replace "V8 JavaScript" with "Node JavaScript."

Reply on news.ycombinator.com