“this” always being evaluated at call time to be the context of the function (as opposed to the semantic scope of variables, determined by the position of the var statement) is the part, that makes Javascript dynamic.

Have a look at prototypes bind() function (or the earlier mentioned built-in apply on which it bases).

It makes writing callbacks much more concise and clear.

The Dojo Toolkit has some neat ways of handling these tricks.

For code loading: dojo.require(‘dojo.xml.*’);

or, use the JS compiler to compress all required files into a single JS.

Problem 2 could be handled nicer in dojo. Many functions in dojo ask for two parameters (object, function) – where the second is the string name of the method of object. I would prefer to use the wrap method you defined above.

Inheritance, although ugly, is fast and clean:

function NewWidget() {

dojo.widget.Widget.call(this);

}

dojo.lang.extend(newWidget, dojo.widget.Widget);

The Prototype toolkit also solves these problems in their own way. Your mileage may vary.

Are you familiar with the way the Prototype library (prototype.conio.net) handles class constructors? It’s essentially the same, but a little more syntactically sugary. It’s still a far cry from useful inheritance.

You’re not really achieving any inheritance benefits with your scheme, since you can never pretend that the subclass actually owns the methods of the baseclass: you’re always referring to the baseclass explicitly when you call a method. That means you don’t get any subtyping abilities (i.e. you can’t just use a subclass object wherever a base object is expected).

Your code does a nice job of pointing out the problem with using normal javascript constructor functions as the initializing functions for your objects. You have to instantiate the object if you want to use it as the prototype for another object, but you really don’t want to run the initialization code in those cases, so it’s best to have the constructor do nothing except (when desired) call the true init function.

Agree that the dynamic scoping of ‘this’ is a foolish default behavior. Prototype has a nice function called bind to handle that problem.

I’ve been working on these problems for a few months now and I think I’ve come up with an extremely usable solution. You can find a demo at http://groupspace.org/devben/prototype/demo.html

The first code snippet is the canonical Prototype syntax for class creation & inheritance; the second is my improvement. The third and fourth are experiments in privacy restrictions.

Note the function this.sup—it resolves to the superclass’s version of whatever method called this.sup. Handy!

Cheers,

Ben

function create_callback(method, object) {
    return function() {
        method.apply(object);
    }
}

i will leave passing the args to the callback as an exercise for the reader.

For what it’s worth, here’s an module that contains examples of solutions to each of these problems:

http://divmod.org/trac/browser/trunk/Quotient/xquotient/static/js/mailbox.js

”// import …” deals with dependencies, the “self” parameter to methods fixes the brokenness of “this”-scoping, and the “subclass” method of “Class” objects (of which Nevow.Athena.Widget is one) makes inheritence a breeze.

Problem 4: Not enough polymorphism

I can’t define equality or comparison for my own types. I’m stuck with JavaScript’s default behavior, which more or less assumes everything is a string. There’s no standard protocol for hash codes; I can (ab)use objects as hash tables, but I can only use strings as keys.

I can’t define an object’s behavior in a boolean context.

Callable objects are only made possible by treating functions as objects, never the other way around.

I can’t redefine the behavior of “for-in” loops, and I can’t override indexing on my own objects so that they can participate in regular “for” loops without code changes. There is no standard iterator protocol aside from array indexing.