3 big problems with Javascript

11 thoughts on “3 big problems with Javascript”

1. Nice article. I completely agree. And here’s one more…

   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.

2. Re: 2, you may be dealing with Internet Explorer issues, not language spec issues. In Mozilla-related products, “this” behaves more reasonably in many cases.

3. Lots of people end up solving these problems when they undertake any non-trivial amount of JavaScript. It’s really too bad everyone has to duplicate this effort.

   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.

4. for problem 2 you can use “apply” to solve it:

   
   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.

5. Keen article.

   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

6. Uh, sorry.. scratch my second paragraph Missed the line “subclass.prototype = new baseclass();”

7. I think the Prototype style “extends” function can be an acceptable work-around. I don’t really like the idea of javascript copying all the prototype elements around, but it does the job with minimal syntax. It really should be part of the language though. It does force 2 layers of indenting on all the class functions which rubs me the wrong way for some pedantic reason.

8. Your CSS is broken. Each Comment gets smaller in text than the last, making it really hard to read anything other than the first two comments.

9. Fixed. Thanks, Matt. It’s always that one last change that’s so simple you don’t even need to test it…

10. I agree with your article. These are the shortcommings of JavaScript, but thankfully theres ways around them.

    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.

11. Problem 2 is NOT a problem but a core principle of javascript (and other dynamic languages such as self etc.).

    “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.