Has there ever been an proposal for a way to modify JavaScript prototypes only inside modules where it's explicitely declared? Basically as in Kotlin Extensions?
http://kotlinlang.org/docs/reference/extensions.html …
Is there an obvious reason this would be a bad idea?
@wycats @domenic @bterlson
The last time it came up it failed allegedly for implementation difficulty (aka performance) reasons. I'm not quite sure why you'd expect lexical scoped object extensions to be hard to JIT but IANAI
-
-
I dunno what the perf impact would be (cc
@bmeurer) but I'm wondering about the mental model. Would the scoping be easy enough to understand, or just add more confusion? And could/should this feature also work outside modules so existing bundling strategies keep working? -
Anyway I guess a lot of languages have extensions of some kind at this point (Scala, Swift in addition to Kotlin); it's not crazy to think of how this could work in JS
-
Due to the dynamic nature of JavaScript this could be quite costly in general. You'd have to do secondary lookups on each "affected" property access in scope. Also this will be fun to spec with eval/with/Function.
-
I think we'd want to define it so that the extensions "win" and can't be changed. This would mean that if you get a hit by the time you're JITing, you can rely on the hit remaining stable.
-
That's a minor thing. You still need to intercept every o.x because of could be one of these prototypes (assuming that x was listed in the extensions). And even worse every o[k] because k could evaluate to a property key in the extension list.
-
Not saying it's not doable, but it comes at a cost.
-
Something in common among the other languages I amdon't aware of which support extensions is that they can be resolved more or less statically
-
Right. I think if we did this we would want very static resolution. I think that's a fair constraint.
- 7 more replies
New conversation -
-
-
Changing the meaning of the . operator to depend on lexical information seems rather expensive, but IANAI either.
-
I'd expect it to be more expensive on lower tiers (closer to "interpreter" modes) but not bad when JITed because the lexical-ness means any piece of JITed code can only have a single resolved meaning for the `.`. Probably matters a lot how dynamic we'd allow these things to be.
-
Bottom line is of course implementability would need to drive another round of this if we wanted to try again.
-
I like the feature, but the refactoring hazard risk seems high. (Or should atleast be considered)
-
Bind operator feels less risky
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.