Comments (9)
I love it. Doing Web IDL implementations in JS, I end up having to decorate methods with brand check wrappers even if I use private fields (due to not wanting the TypeError message to reveal implementation details). So far I’ve addressed that by keeping a Weak collection in the mix even when private fields would have been sufficient for maintaining the actual private state.
This would make it more natural to drop the extraneous weak collection in favor of using private fields even in the condition for when we “manually” throw the “Illegal invocation” TypeErrors. One less moving part in the mix: 👍
Re: syntax — this seems intuitive to me (partly due to the hint of symmetry with typeof foo not throwing a ReferenceError when foo is undefined).
from proposal-private-fields-in-in.
I can list alternatives I can think of?
-
Meta properties :
#x.has(o)
or#.has(o, #x)
- from thinking of private fields as WeakMaps. Definite preference for#x.has
of those 2. This still does not expose the value as first class, but if the value is first class as#x
rather than a reference syntax, it would be a problem (same for current proposal). -
Pseudo fn like
import()
:in(o, #x)
- this has a serious downside of0 in([], [1])
already being valid. This does not have problems with#x
being a first class value rather than a reference syntax. -
Disambiguate the operator between public/private :
#x #in o
- this seems weird, and I don't see reason to keep them separated currently except prototype crawling differences. -
New contextual operator for own props using member expression akin to
delete
:own o.#x
- shouldn't usehas
due to proxy trap naming being forin
. Naming bikeshed. Could be useful, but seems a bit out of scope. Unclear if this is added whyin
wouldn't also be useful for code refactoring purposes.
from proposal-private-fields-in-in.
o?.#x
doesn't seem very useful if it can throw. So what if it also checked the presence of#x
before trying to access it?
If this change was made, returning undefined
can also imply that the left-hand-side was null
or undefined
. So the full check would need to be:
const hasField = o !== undefined && o !== null && o?.#x !== undefined;
And, as you say, this pattern would be limited to situations where the private field was guaranteed to never store undefined, which may not always be desirable.
from proposal-private-fields-in-in.
Right you are, mine was unnecessarily verbose.
Might also be worth noting that this would be a breaking change for any code that is relying on invalid private field access throwing. It also appears this was discussed as part of the optional chaining proposal here: tc39/proposal-optional-chaining#28
from proposal-private-fields-in-in.
The in
solution reached stage 2.
from proposal-private-fields-in-in.
I have a question and it probably doesn't deserve its own issue, so posting here.
Could this be solved with an additional check in optional chaining operator?
o?.#x
doesn't seem very useful if it can throw. So what if it also checked the presence of #x
before trying to access it? You wouldn't be able to distinguish between #x not in o
and o.#x === undefined
, but since you have full control over #x
(right?), you can make sure it never becomes undefined
. And then you can interpret o?.#x === undefined
as missing.
from proposal-private-fields-in-in.
const hasField = o?.#x !== undefined;
Would give the same result every time. When o == null
, optional chaining returns undefined
immediately even before the additional check I suggested.
I was drawing from the rationale for this proposal, which asks for a way to silently "check if an object has a private field". null
and undefined
naturally don't have private fields, there's no discrepancy.
from proposal-private-fields-in-in.
Thank you, that completely answers my question. This additional silent check was considered, and rejected in favour of consistency with other kinds of optional chaining. Which makes sense, even though none of the examples presented in that thread convinced me that o?.#x
throwing is actually useful (quite the opposite).
from proposal-private-fields-in-in.
It’s quite useful, and was a necessary part of the design of class fields - but that’s also irrelevant, since that proposal is stage 4 and this one can’t change it, for the reasons mentioned above.
from proposal-private-fields-in-in.
Related Issues (12)
- Explicit first class private name alternative HOT 18
- Some thoughts about this proposal HOT 8
- Class brand HOT 26
- No need to support strong class inheritance checks here HOT 3
- Update readme to clearly mark chosen solution and its behaviour
- in test HOT 6
- `in` does not preclude shorthand? HOT 11
- Object.hasBrand(obj, cls) alternative design HOT 23
- Forbidding references to undeclared privates HOT 2
- Path to Stage 4! HOT 9
- Is it better to use try expressions? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-private-fields-in-in.