JS Class fields potentially harmful

I have questions Spec Reading
61

this is indeed why both my custom-function extend works (fields installed on return override) and so does nonchalance which indeed extends via updating and overriding the returned field so I am guilty myself to abuse the current fields situation and nothing would work if new.initialize doesn't get approved or moves forward.

I do still feels extremely hacky in my libraries, but at least the returned override is an instance of the expected super and sub class, so it's easier to reason about and explain in its current shape.

Returning a non instance though is a whole new world of issues to explain, as nothing else in the prototype chain can work with fields likely defined to work within methods and/or accessors defined in the prototype, not just as shortcut to set something in the constructor, but specially on the DOM fields with arrows (as mostly nobody uses handleEvent out there) will backfire on extend ... every, single, time.

Thanks for the hints / explanations and the pointer to new.initialize :+1:

62

Btw, I rest my case. I didn't know fields have been around so long and definitively it's late to change these at this point, and even my code abuse the current implementation so it's clear there are situations where that is meant/needed. It would still be awesome if in the future there could be a way to handle these, as right now it's inevitably hidden and unmanageable so I hope this thread won't be forgotten for the future of the language.

Thank you all for chiming in with thoughts and pointers :wave:

1 Like