41–50 of 52 posts
Earlier quoted context omitted.
Even React is de-emphasizing class inheritance in favor of more function components.
Yeah and with hooks they arent even necessary at all anymore.
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 sh…
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 sh…
Earlier quoted context omitted.
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…
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 ar…
Immutability and thinking about if a class should really be stateful are the major wins.
I was recently looking over some code that essentially just did transformations, but all the inputs and outputs were member variables, so it took some effort to track what creates what and what depends on what. The members also had empty defaults, so if you mix up the order you call the functions in, the code still appears to work. It wasn't "wrong;" it was hard to follow and error-prone.
Earlier quoted context omitted.
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.
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 i…
To which all youth ever just roll their eyes.
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
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…
Go only took the method syntax from Oberon-2, package initialization and unsafe instead of SYSTEM.
As someone quite in love with functional programming (background in Haskell and Scala), one thing that seems quite obviously missing here and in my Javascript experience so far is the use of typeclasses as a form of ad-hoc polymorphism. Is there a nice (i.e. not too much boilerplate) way of using them in the land of Javascript/Typescript?
See https://github.com/gcanti/fp-ts . Heavily haskell-inspired and includes a TS implementation of higher-kinded types.
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.
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.
Earlier quoted context omitted.
See https://github.com/gcanti/fp-ts . Heavily haskell-inspired and includes a TS implementation of higher-kinded types.
This is definitely the best option in the TS ecosystem but it's not meaningfully implementing typeclasses from the perspective of the end user. There's no single `fmap` for example, instead you'll be using dedicated `Array.map`, `Option.map`, etc.