[HN Gopher] How JavaScript works: 3 types of polymorphism
___________________________________________________________________
How JavaScript works: 3 types of polymorphism
Author : zlatkov
Score : 44 points
Date : 2021-05-07 10:55 UTC (2 days ago)
(HTM) web link (blog.sessionstack.com)
(TXT) w3m dump (blog.sessionstack.com)
| rahulsingh789 wrote:
| nice
| jollybean wrote:
| The very title is kinda scary, in the context that everything was
| kind of hacked onto JS. While it's probably important to
| understand, the 'answer' I think, without being ham-fisted, is
| probably to use Typescript in most cases.
| vgvvgvhvh wrote:
| This isn't the sort of website where you can criticize tools
| and languages like a hacker might. This is a forum for people
| with hire people who will inevitably be forced to make products
| using these tools for this tower of babel-esque dumpster heap
| we call the web stack.
|
| Just because this forum is called hacker news don't get your
| expectations twisted. We're only here to boost engagement for
| acquisitions and "growth hacking"
| FractalHQ wrote:
| As someone new to JS, a friend of mine insists that I always use
| classes and inheritance, and that functional style / composition
| is bad. However, most of the newer libraries I read through all
| seem pretty functional, whereas the older ones are full of
| classes. Personally, I find myself writing everything with
| factory functions and composition because it feels natural to the
| way I think about code.
|
| Am I wrong, and should I be listening to my friend? He has much
| more experience than me.
| fiddlerwoaroof wrote:
| I'm mostly the opposite: classes in JavaScript feel like a
| kludge invented to pretend JavaScript's version of OOP is what
| people were familiar with in languages like Python, Java and
| C++.
|
| If I'm going to write OOP JS, I generally prefer to use object
| literals and Object.create. However, I've mostly switched to
| the "Unix philosophy" style that libraries like Ramda promote:
| lots of sharp tools that are composed to build your programs.
| mxxx wrote:
| In my personal experience, the class syntax specifically gets
| used very infrequently. Proper prototypal inheritance was more
| common "back in the day" but my own preference and I _think_
| what a lot of others are leaning towards these days is
| composition.
|
| Learn to use both and make up your own mind!
| langager wrote:
| I've been getting paid to write JS/TS for about 10 years. I
| think I've used the `class` keyword less than 5 times in the
| last 5 years and feel better off without it. I've found that a
| more functional style leads to better separation of state/data
| from any logic you have to write, allowing for a better testing
| experience and an easier time refactoring. Plus it means I have
| to think way less about what `this` means.
|
| At the end of the day, features of languages are just tools,
| and sometimes they fit the problem you're trying to solve. I
| think it's also important to decide what tools to use in the
| context of what experience you and your team already have.
|
| Also, it's hard to have small .js files when you use classes,
| and I love small files. I think Go made a great design decision
| to allow functions on structs to be implemented in separate
| files.
| cout wrote:
| I once heard someone tell me that good OOP ends up looking
| very functional. I've taken that to heart, and I believe the
| code I write is better as a result.
|
| I do use the `class` keyword in my js, but I'm also on a team
| of C++/Ruby programmers who are forced to write js, so the
| more I can do to make it more familiar, the better. As you
| said, it's just a tool. Some people like nails and some
| people like screws; there are objective advantages to each,
| but either one will hold a house together.
| jollybean wrote:
| Using 'classes' doesn't imply OO. They're a perfectly good
| way to organize data, at very least for data objects in TS.
|
| It's fine to want to go functionally heavy, but if you're not
| using classes - which are the foundation of 'types' - then
| why bother with 'type'script? (Unless you mean to say
| 'interface'? Which is obviously not 'class' but implies the
| same usage of OO-founded keywords)
| jrsala wrote:
| Pure functions, polymorphism, inheritance, composition, factory
| functions, classes... All of those are tools. They have
| benefits and drawbacks that are circumstantial (they depend on
| the language, the problem, the time pressure to ship, the skill
| level of the team, and many more other factors). Extremely
| successful codebases have been written using almost any
| combination of those tools. What those codebases have in common
| is that the people who wrote them understood their tools. So if
| I were you I would strive for understanding.
|
| In that spirit, it's good that you question what experienced
| people tell you. What about asking your friend to explain why,
| at a fundamental level, their recommendation is good? "Always
| use classes and inheritance" as a hard-and-fast rule is not
| very helpful.
| elchief wrote:
| I'd say inheritance is NOT a good use-case for Person / Employee
|
| A person can play many roles, at the same time. Composition is
| better in this case. A person has many roles
|
| Inheritance is better for types of legal parties though (see The
| Party Model). A person is a legal party. An company is an
| organisation is a legal party
| wmichelin wrote:
| Love to see this line of thinking taking over in the industry.
| Languages like Go make this type of object relationship super
| easy.
| [deleted]
| nine_k wrote:
| I'd say that inheritance, with method overriding, is the worst
| anti-pattern of mainstream OOP, which contains a number of
| otherwise sound ideas, like encapsulation.
|
| I like the Go's approach to that (taken from Oberon), and the
| Rust's system of traits.
|
| In one large codebase I saw there was a rule to make classes
| either abstract (without implementation of key parts), or
| final. Everything else is done via interfaces and composition.
|
| See
| https://en.m.wikipedia.org/wiki/Composition_over_inheritance
| plexicle wrote:
| I personally think composition is better in almost every
| imaginable case. But I suppose that's an argument for another
| thread.
| rcgorton wrote:
| Hmm. Dumb, Dumber, and Dumberer
| zanethomas wrote:
| I can't remember the last time I even considered using
| inheritance in javascript ... except to consider it unnecessary
| and strewn with mines.
| jrsala wrote:
| There is a lot of wrong in this article: inability to articulate
| what polymorphism is, misunderstanding of prototypes, bad JS
| practices (`var`, `.__proto__`), falsehoods on programming
| languages including JS itself, confusion around ECS, unfinished
| examples... I suspect the author is in the early stages of their
| learning journey and Dunning-Kruger is in full effect.
| plexicle wrote:
| You might be right but your last sentence is the reason why
| people are apprehensive about sharing their work and writing
| more articles. There's no need for it.
| jrsala wrote:
| There is no judgment in what I said. DK is a fact of life and
| we will all experience it at some point. I know I have, and
| quite badly.
|
| I wish when I was younger someone had told me "look, you
| don't really know what you're talking about, here's how
| things really work". If no one tells you, how long does it
| take for you to realize and how much time do you waste
| thinking you know what you don't know? Again, the author is
| at the start of their learning journey. I'm not saying
| they're a bad person or a hopeless case.
|
| And finally, people should not be apprehensive about sharing
| their work in general, but I think they should be when
| writing articles that purport to teach others.
| jollybean wrote:
| The problem is JS - it's been a fuzzy bit of confusion since
| inception, it was never remotely intended to do what it's
| doing, and nary a tiny fraction of JS developers could
| authoritatively explain the differences between prototype
| __proto__ etc. - I keep a chart handy as a reminder and much
| like C++ stick to a set of rules to avoid unknowns.
|
| There's a reasonable chance that with a much more succinct and
| clean '20/20 hindsight' the articles like this would be either
| clear, or frankly unnecessary.
___________________________________________________________________
(page generated 2021-05-09 23:01 UTC)