-
Notifications
You must be signed in to change notification settings - Fork 19
Rewrite in terms of internal slots #42
Comments
I also sketched this out in the proposal that Yehuda and I developed. Be sure to look at the semantics sketch section. Fill free to borrow... |
Hi @allenwb @erights, I've modified the draft specification in terms of slot keys and an |
README.md still mentions WeakMaps |
WeakMaps is how this feature will be polyfilled, regardless of how it's worded in the spec, and some members of the committee do indeed prefer using them to explain the concept more clearly than the concept of "internal slots". I think it should be fine to mention it in the readme. |
@chicoxyzzy Thanks for pointing this out. I've rewritten that part of the README to be in terms of the current spec mechanics, while pointing out the analogy to WeakMaps. |
I talked to @littledan this week to clarify a couple of things, and I will take a stab at it over the weekend, specially to modify the grammar from babylon. |
@diervo, make sure you check babel/babylon#158 - babylon's grammar for class fields is currently rather far from spec. |
@bakkot thanks! Yeah I was digging into babylon first to understand how some of the current implementations were done (like decorators and public fields) and it looks less "spec formal" as I expected. Will hopefully send something soon to gather feedback. I'm fortunate that @littledan will help me in the nuances to make sure is spec compliant :) |
@allenwb and Waldemar expressed concern that the WeakMap semantics had poor layering properties and implied unexpected GC semantics. One way to repair that would be to use internal slots to track private fields, rather than WeakMaps. Kevin actually did this in an earlier version of the spec. GC and layering aside, I believe there aren't any observable differences with this formalism. This bug tracks making that spec change. cc @erights
The text was updated successfully, but these errors were encountered: