Will JavaScript ever become a 'proper' class based language? [closed]

Question

I'm referring to MDN's article on JavaScript's 'future reserved words' (for use in the new strict mode) - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Future_reserved_keywords . All the reserved words indicate that JavaScript will possibly follow a non-prototypical inheritance procedure, but what does this mean for already developed applications and modifications? Does anyone know how long these have been 'future reserved words', and whether or not these changes will come to light in the near future or not?

If this isn't the right place, feel free to move it.

Preoccupation

it doesn't fit in here definitely. I would suggest you to manually migrate this question to Programmers SE – Labionasal

I think most have been reserved for as long as ECMAScript has been around. No, I don't think JS will ever be a traditional class-based language, but I believe ECMAScript 6 will be using the class keyword for a syntactic sugar over prototypal inheritance. – Nekton

...here's a link to the ECMAScript first edition PDF (1997). It shows class in its list of future reserved words. – Nekton

good god i hope they don't ruin JS; we have enough proper languages already and they are taking a backseat to improper JS for a reason... – Recuperator

Answer 1

Will JavaScript ever become a 'proper' class based language?

Fortunately, NO. It is already a proper language even without being class-based. You will never loose the power to create objects without classes.

I'm referring to MDN's article on JavaScript's 'future reserved words'. All the reserved words indicate that JavaScript will possibly follow a non-prototypical inheritance procedure

No, it's very unlikely that they will give this up. They just want to keep all options open to implement these functionalities, and want to prevent you using this syntax.

Like the Harmony drafts for classes and the current ES6 proposal show, most of these concepts can be implemented well in a prototypal world.

but what does this mean for already developed applications and modifications?

Not much. All changes in EcmaScript try to be as backwards-compatible as possible (remember what all this hassle with strict mode is about?).

Does anyone know how long these have been 'future reserved words', and whether or not these changes will come to light in the near future or not?

The article gives a good overview, I think. You may want to compare ES3, ES5 and the ES6 draft (maybe even earlier versions).

As said above, these are not intended to become "changes". Don't forget that back in the dark old days JavaScript syntax was based on Java, and did inherit its set of keywords. The removal of the Java types, and the addition of new keywords for more powerful concepts, can be seen as setting a direction in the development of EcmaScript.

Winnebago

Answer 2

All the reserved words indicate that JavaScript will possibly follow a non-prototypical inheritance procedure

Not at all. There is a difference between syntax and semantics. Only because you are creating classes with the class keyword in Java, doesn't mean that's what is happening in JavaScript as well. Under the hood, the languages behave differently.

ES6 introduces the class syntax:

class Person() {
  constructor(name) {
    this.name = name;
  }

  static create() { }

  sayName() {
    console.log(this.name);
  }
}

Looks like a "class" right? But it's just syntactic sugar for constructor functions and their prototype object:

function Person() {
  this.name = name;
}

Person.create = function() { };

Person.prototype.sayName = function() {
  console.log(this.name);
};

The static keyword defines the function on the constructor function instead of the prototype (e.g. Person.create instead of Person.prototype.create).

Similarly I could imagine that final will define the property as not writeable and not configurable, at some point.

---

Bottom line: It's rather unlikely that the fundamental concepts of a language such as JS change completely.

Disport

+1, however final would probably mean that the property is not allowed to be shadowed on objects that inherit from it. – Winnebago

That's what writeable: false implies: jsfiddle.net/SpPyc – Disport

Yes, but only for assignment. setProperty is not affected by this: jsfiddle.net/SpPyc/1 (but I'm sure they'd figure out something reasonable if they wanted to implement final :-) – Winnebago

Uh... point taken :) I just wanted to demonstrate how new syntax can be expressed by existing functionality. Of course for some things we actually have to add or change behavior (e.g. block scope). – Disport

Answer 3

In direct answer to the question, no; this would be a huge fundamental shift in the language.

Most of those have been reserved for ages. One of JavaScript's biggest flaws is NOT that it is a prototypal language, but rather that it in some ways tries to masquerade as a classic OOP language to make it feel more familiar to the old guard.

Neither class based nor is prototype based is inherently wrong or correct; but they are very different. Other prototypal languages have been around for along time, but they had not experienced as much popularity and subsequently familiarity to developers as class based languages.

A great comparative definition I have seen used for this is the following, courtesy of Eric Elliott.

Class based : OOP => Object ORIENTED Programming

Prototypal based : OOP => Object ONLY Programming

There is also a great video available from Eric on Prototypal inheritance here

http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/

And IMHO, one of the best reads over on Prototypal vs Classical inheritence; not even a technical read, but rather more philisophical.

http://carnotaurus.philipcarney.com/post/3010984357/classes-versus-prototypes-some-philosophical-and

Goatish