Skip to content

Update 5_6_1_Pattern_Monad_1.md #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Halochkin wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update 5_6_1_Pattern_Monad_1.md #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/newChapters/the_law/5_6_1_Pattern_Monad_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ Commonly, monads are described as being created by a plain `function`s, not `con
3. The `new` and `constructor` pattern in JS is a bit flawed:
1. JS doesn't allow `constructor` overloading. This means you *must* have only *one* `constructor` per class. This doesn't really fit well with the class concept in general, nor monads in particular. What *can* happen is that you end up cramming *two or more different functions* into *one constructor*, which then *can* fill your `constructor` function with super fragile, god-awful argument type and value checking, extra arguments to identify which variant of the `constructor` that you intend to call, etc.
2. Whenever you write `new` in your code, then the JS engine *must* create a new object. This is bad if you need to reuse objects from your own pool of objects. Put simply, you can't memoize nor reuse a `new` thing.
* However, there is a way out of this dilemma: `static` factory functions. You can have many factory functions (no need to cram many functions into one), and you can make the factory functions manage your pool of objects (it's fine to memoize and reuse static factory functions). `class`, `new`, `constructor`, and `static` factory functions is a viable OO pattern.
3. However, there is a way out of this dilemma: `static` factory functions. You can have many factory functions (no need to cram many functions into one), and you can make the factory functions manage your pool of objects (it's fine to memoize and reuse static factory functions). `class`, `new`, `constructor`, and `static` factory functions is a viable OO pattern.

The counter argument advocating for `class` and `constructor` syntax is that they explicitly marks the *role* of the `class` in particular and clearly identify which functionality will be needed by *every* object instance created. It is a step in the direction of making JS a more statically typed langauge. And this yields *three* benefits when using the `class` and `constructor` pattern to create monads:

Expand Down Expand Up @@ -135,4 +135,4 @@ Here is my rules of thumb for making monads in JS:

## References

* [Eric Elliot on OO, constructor, new, class, and extends](https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3)
* [Eric Elliot on OO, constructor, new, class, and extends](https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3)