(Look at Io if you want to see prototype-based inheritance done right. The guy who wrote it is a gifted programmer, though I’m pretty sure he and I sit at completely opposite ends of the political spectrum…)
But prototype based inheritance in JS is just shit. It is badly implemented parody of Self, where it actually makes sense.
Could you elaborate on the differences? I’ve never looked into the specifics of Self’s prototypical model, but am curious about how it compares with JS’s.
I wrote a bit here about some of the differences between prototype based languages and Self.
Great article, I forgot how nice Io’s syntax is. I had not heard of the “organising program without classes” before.
If one programmer uses your language feature badly, maybe they’re a bad programmer. But if every programmer uses your language feature badly, it’s probably a bad language feature.
Ha. Ha ha. HAHAHAHAHAHAHAHAHA.
It’d be less funny if this shit wasn’t the bane of my career. Some folks tried to warn others about adding new cruft, but we were ignored and/or mocked.
Anyways, a point the author doesn’t bring up that’s essential to proper vulgar-OOP (e.g., Enterpriesy heavily inheritance-based) stuff: there still is no way of properly handling visibility, for things like protected and private.
Seriously, look at this abortion. Look. at. it.
All that happy horseshit about modules and tree-shaking and all that, and I can’t make a for-real no-sharing private class method without resorting to acrobatics? Srsly?
Why are you trying to put lipstick on this pig instead of using better tools?
Because this pig brings home the bacon.
I agree with you, mind you, but the problem is that the quality of this tool is actively declining as they keep adding shit to the language. And to the ecosystem. And to the tooling.
What better tools? If your use-case involves JS, there’s not much that can done about that.
This encouraging to hear. I hope this becomes more commonplace over time.
I’m hesitantly very-much-for the static typing revolution. (But iff it increases security and programmer productivity).
Things like this are the raw materials that fuel compile-to-js languages…
That’s fair, although even in compile-to-js languages it is difficult to escape JS entirely.
PureScript - only use JS via the FFI for performance or interop reasons.
I’m not sure what kind of benefit you would get with having private/protected slots in a dynamic language. It’s mostly a compiler’s business to enforce access permissions, and there are plenty of transpilers with this kind of features to choose from.
I would have personally preferred JS to improve its core model and runtime so that transpilers can be implemented more efficiently, instead of adding sugar and complexity to a clunky language. Thank God, Webassembly is coming.
Even Python can hide things from you, which is super useful if you want to alter an object’s state without exposing all the plumbing.
Are you referring to the __ slot prefix? It’s not the same semantics as access protection, as in Python it will rewrite the slot name on assignment but it’s still going to be accessible afterwards (under the rewritten name). I’d be curious to know if you were thinking about another feature in Python that I’m not aware of.
It’s that but accessing the rewritten name is obfuscated enough that it’s hidden for all intents and purposes, at least in my book.
I’d tend to agree that complete protection is a hassle/impossible without a compiler, but IMO the Python solution blows at least JS out of the water.
Python, Perl, and Ruby don’t have private/protected either, so this is a thin argument to hang your hat on. There are much juicier targets when contemplating js flaws.
Do i know you? You remind me of someone i know. Also, to answer your closing question: no, you can’t. Not that I’m aware of.