JavaScript: prototype vs. class

Re:JavaScript: prototype vs. class by couchand on Wednesday April 04, 2018 @10:18AM (#16754889)

It's purely syntactic sugar. You can even get the new protection yourself:

    function Cat() {
      if (!(this instanceof Cat)) {
        throw new Error("please use new!");
      }
    }

or, if you want to be a bit nicer to your users:

    function Cat() {
      if (!(this instanceof Cat)) {
        return new Cat();
      }
    }

[ Parent | on HN ]

Re:JavaScript: prototype vs. class by danlugo92 on Wednesday April 04, 2018 @11:26AM (#16755614)

Seems like the 2nd option might prevent me from using Cat's as a mixin

[ Parent | on HN ]

Re:JavaScript: prototype vs. class by hajile on Wednesday April 04, 2018 @12:55PM (#16756578)

Mixins have terrible performance characteristics and lead to fragile code. While they were huge a few years ago, most new frameworks either avoid them or (in cases like React) chose to remove them for these reasons. In an existing codebase, that matters a lot. In newer codebases (or newer parts of existing ones) it shouldn't matter that much at all.

[ Parent | on HN ]

Re:JavaScript: prototype vs. class by danShumway on Wednesday April 04, 2018 @11:35AM (#16755693)

Both options will break mixins.

  function CatDog () {
     Cat.apply(this, arguments);
  }

  CatDog.prototype = Object.assign(Dog.prototype, Cat.prototype);

In the above example, CatDog is not an instance of Cat, since it never actually inherits from the Cat prototype.

[ Parent | on HN ]

Re:JavaScript: prototype vs. class by spiralx on Wednesday April 04, 2018 @01:16PM (#16756819)

Mixins in ES6 should be functions taking a class and returning another class that extends it:

https://alligator.io/js/class-composition/

[ Parent | on HN ]