I agree, this topic fits better for JS forums. There is no big need to
discuss here prototypes vs classes (it's simply about code reuse with
different styles, and is searchable on many JS forums/articles). This
mailing list is for the language design and implementation.
Dmitry
On Sat, Jun 29,
[Fixing empty subject.]
Chris Ryan wrote:
Do we need classes at all? In my opinion, given that the concept is
implemented in a clear manner and it is possible to be powerful enough
to be of use in favour of prototyping (and developing based on the
prototypal concept instead), then yes, it
LinkedIn
J'aimerais vous inviter à rejoindre mon réseau professionnel en ligne, sur le
site LinkedIn.
Marc
Marc Alcaraz
Consulting and senior engineer and RD chez DozroK
Région de Marseille , France
Veuillez confirmer que vous connaissez Marc Alcaraz :
Brendan,
You seem to only be replying to the most recent comment in this thread, and
not considering the objections that I raised at the beginning of the
thread. My argument is that class isn't just a little bit of sugar. I
believe that counter to its goal, it will reduce programmer productivity
JS is a rich language that allows different styles of programming. Nothing
wrong with that.
What's wrong is that when we give people `class` and `extends`, books and
blog posts everywhere will begin to teach that this is how we do
inheritance in JavaScript, ignoring all the perils that go with
I don’t think you appreciate how hard it was to reach the consensus for
ECMAScript 6 classes (lots of incredibly long, incredibly passionate
discussions!)
I do appreciate it, and I bit my tongue for much of it, but as the idea of
class in JavaScript has been catching on more in the last couple of
I know that JavaScript doesn't lose its dynamic nature when we add class,
but, to bring back an earlier example, say you start with:
Animal
* Walking
* Human
* Ape
* Flying
* Bird
* Bee
* Swimming
* Fish
* Whale
Now you need alligator and duck. Alligator clearly needs
Honest question: how can this problem not be solved via ES6 classes plus
mixins? The original hierarchy already feels wrong. Why not create a
super-class Animal, with sub-classes Human, Ape, Bird, Bee, Fish, Whale
plus the mixins Walking, Flying, Swimming?
I completely agree with you, but in the
Couldn't you just do:
var squaredSmalls = Int16Array.from((v*v for v of smalls));
Or is the allocation of a generator expensive enough to warrant the mapFn
argument? Alternatively, is it the need to support a map on a non-iterable
array-like?
Ron
Sent from my Windows Phone
To me, single inheritance has always been the skeleton on which I hang multiply
inherited pieces. That skeleton doesn’t even have to be a hierarchy, it could
be a set of classes.
Maybe you simply need to write a mixin or trait library that works well with
ES6 classes?
Axel
On Jul 1, 2013, at
That skeleton doesn’t even have to be a hierarchy, it could be a set of
classes.
Then you don't need `extends` or `super`.
- Eric
On Sun, Jun 30, 2013 at 4:42 PM, Axel Rauschmayer a...@rauschma.de wrote:
To me, single inheritance has always been the skeleton on which I hang
multiply
On Sun, Jun 30, 2013 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote:
[Fixing empty subject.]
Chris Ryan wrote:
Do we need classes at all? In my opinion, given that the concept is
implemented in a clear manner and it is possible to be powerful enough
to be of use in favour of
12 matches
Mail list logo
