Will there be a new way of managing javascript classes?

Does anyone know if structuring javascript will be changed? What I mean is to have a way to manage javascript classes into packages, like in Java. Is there开发者_运维技巧 already a way?

I guess you are familiar with the Java concept of naming packages after a domain you own, this way avoiding collision with the packages of other vendors. You can simulate Java packages (and avoid possible naemspace collisions) with:

if (typeof(org) == "undefined")
    org = {};

if (typeof(org.mydomain) == "undefined")
    org.mydomain = {};

if (typeof(org.mydomain.mypackage) == "undefined")
    org.mydomain.mypackage = {};

org.mydomain.mypackage.MyClass = function (newA) {
    // constructor
    this.a = newA;
}

org.mydomain.mypackage.MyClass.staticMethod = function () {
    // static method
    return "static";
}

org.mydomain.mypackage.MyClass.prototype.method = function () {
    // normal method
    return a;
}

var o = new org.mydomain.mypackage.MyClass(13);
console.log(o.method());
console.log(org.mydomain.mypackage.MyClass.staticMethod());

You can even simulate Java's import if you are working in a limited scope. (Doing this in the global scope would eliminate the whole point of packaging):

function afunc() {
    var MyClass = org.mydomain.mypackage.MyClass;

    var o = new MyClass(33);
    console.log(o.method());
    console.log(MyClass.staticMethod());
}

The weakest link here is the root of our namespace, org (or com or any top level domain). An other class may use it for some other reasons. Using org_mydomain as the root instead of org.mydomain may give some safety.

Edit:

You have other possibilities for the root name too if you want to avoid using TLD as the root. If your domain name is unique enough (for example a hip misspelled one like foogz.com) you can assume that there will be no other company writing reusable JavaScript classes who will go for foogz.org or foogz.biz, so probably you will be the only foogz out there. :)

An other possibility is to append your TLD to the domain name and use that for the first tag for example: mydomainorg.packagename.ClassName.

There are no JavaScript classes. There are only Objects. You can pack a bunch of objects into a different object, and treat it like a module/namespace if you wish. (example at the end.)

Because of that, there can't be any "improvements" in the field of JavaScript classes because there aren't any, and I hope there won't ever be either. And frankly, that's for the best. Would you rather deal with insane getters/setters, static members, protected, type coercion and so on etc? Prototypal inheritance beats "Classical inheritance" by miles. It's just that JavaScript didn't have too much time to get it just right.

For amazing explanations on how JavaScript objects work, I recommend Douglas Crockfords' "On JavaScript", or some answers from our very own members.

An example of "namespacing":

var obj = {

    classRoom : {...},
    objectify : function() {...},
    capacity : 5
};
var myClass = obj.classRoom; //access it like you access a module
var capacity = 7; //this is a global variable named capacity, so it won't tamper with obj.capacity

Check out http://joose.it, it has a great module system (library, not language extension). The 4th edition of the ECMA-262 spec has packages, and it's implemented in actionscript.

There is some speculation (e.g. by John Resig) about new features like object freezing and packages that might be added to ECMAScript Harmony (a.k.a 6th Edition).

However, I personally doubt that the language committee would consider such a drastic change to the way the language handles some of its core OO principles.

JavaScript is dynamic code in a file. All you do is load some source code and run it dynamically.

Every structuring and managing system is dynamically written and done at runtime. There are lots of ways you can manage and structure javascript code.

• requirejs check define
• yui check YUI.add
• dojo check dojo.provide
• and more

Personally I recommend requireJS as it's not tied into any framework / other libraries.