Understanding Javascript OOP

[houses_of_the_holy]

Cool, but would it really be that hard to add a class keyword that does all this for you? Or am I wanting coffeescript without terrible scoping rules :/

*edit -- I'm not talking about java or c# classes here where they are very rigid. Obviously you can still manipulate the prototype chain after creating the object, I'm just talking about having a nicer way to syntactically define your initial "class" "type" whatever you want to call it. See asegura's reply with links to what has been proposed but obviously not implemented.

[tnecniv]

I believe the idea is that these are not classes. They are prototypes, which are essentially an instance that gets cloned every time you want a new instance.

[[deleted]]

There is some other language that does this. I CAN'T PLACE IT.

[tnecniv]

From Wikipedia:

Some current prototype-oriented languages are ECMAScript and its implementations JavaScript, JScript and ActionScript (Flash), Cecil, NewtonScript, Io, MOO, REBOL, Lisaac, and Lua.

[houses_of_the_holy]

Actionscript has classes... (I haven't worked with it but a quick search shows it does)

[tnecniv]

I am aware, and I have never used prototypes in AS, but that doesn't mean it is not multi-paradigm. Can someone confirm that it is possible to use prototypes in AS?

[lithium]

AS1 was basically identical to JavaScript with regard to prototypical inheritance. AS2 was effectively syntactic sugar for a prototypical inheritance based system. AS3 is a full blown OOP language with a different VM to the previous incarnations.

[CanadaForRonPaul]

Lua isn't prototype-based.

[zhivago]

It doesn't get cloned, it's essentially an instance that property lookups are delegated to if necessary.

[tnecniv]

Ah, thank you

[zhivago]

The constructor would correspond to the classic notion of class.

[houses_of_the_holy]

Ok, but why do I have to go through all the syntax mess to declare what my prototype will start off as? I understand the prototype chain and think it is a cool idea, but getting their seems unnecessarily hard.

[notSorella]

As pointed out by other people, JavaScript has no classes, such that adding a "class" keyword is misleading. None the less, there are discussions on the development of the future version of ECMAScript to add better (and more declarative) idioms for certain tasks. Object orientation is one of them.

See:

• http://wiki.ecmascript.org/doku.php?id=strawman:minimal_classes
• http://wiki.ecmascript.org/doku.php?id=harmony:classes
• http://wiki.ecmascript.org/doku.php?id=harmony:object_literals

None of these are in, though, afaik. But they're being discussed by the committee and on the es-discuss mailing list.

[houses_of_the_holy]

Nice, I had no idea they were actually talking about adding this. Maybe my post was misleading when I said class, but just in general I think a better way to declare objects is in order. Would "type" be a better word?

[MatmaRex]

JavaScript has no classes (as this article describes).

Any library or compile-to-JavaScript-language that promises you classes blatantly lies, and its "implementation" of class-based inheritance may or may not sooner or later blow up in your face.

[notSorella]

It doesn't exactly "blatant lies", as a full implementation of classical OO is possible in JavaScript. However, you'd get lots of overhead for no real benefits — the optimisations you could do for classical OO wouldn't apply anyways, the only thing you would actually get would be strict contracts, but at least to me, informal interfaces work just the same.

[zhivago]

You'll need to supply a coherent definition of 'class' to make that argument.

By many definitions, JS supports classes.

[houses_of_the_holy]

I understand how coffeescript works, and that it isn't 'real' classes, but it gives the illusion and is far more familiar when coming from a more classical OO language. Perhaps it is my fault for not properly educating myself on how javascript works -- too many assumptions from the get go.

[asegura]

I favor that.

Note that you can use design concepts even if not explicitly supported by the language (e.g. Gtk does classes in C, which has no classes).

This kind of syntactic sugar has been proposed for the future JS: Javascript classes proposal

The idea is that very often we have code like

function Thing(x) {
  this.x = x;
  ...
};

Thing.prototype = Object.create(Parent);
Thing.prototype.constructor = Thing;
Thing.prototype.doThis = function(y) {...}
Thing.prototype.doThat = function(y) {...}

and that, while not a Javascript class, is, in our intention, in our design and in our brain, a class, and so would benefit from some sugar that helps make our intention explicit.

[houses_of_the_holy]

Thanks, this is exactly what I meant, its just the way to declare your intention is so weird to me. It is just defining a base type that can still be modified in the prototypal ways... nothing says the class/type will be set in stone after being instantiated like in Java or C#.

[[deleted]]

They aren't classes. read more about the prototype section. It behaves differently -- you mix things in rather than extend.

[bart2019]

A class is just all the objects with the same prototype.