stephenwoods.net

So I have cleaned up EvilScript, now a full featured downloadable thing. Its actually basically one function, about 30 lines. It allows you to write JS in a “classical” style, if thats your thing. The name “EvilScript” should give you an idea how I feel about the idea, but I spent this evening cleaning this up, so enjoy. Download the minified file here.

Using this is really simple. No support for public/private methods, but this is really just object cloning with inheritance:

var vehicle = {

		_init:function(){
			console.log('vi');
		},

		numwheels:0,

		running:false,

		start:function(){
			this.running = true;
		},

		stop:function(){
			this.running = false;
		},

		isRunning:function(){
			return this.running;
		},

		setWheelNum:function(num){
			this.numwheels = num;
		},

		getWheelNum:function(){
			return this.numwheels;
		}
	};

	var car = {
		extend:vehicle,

		_init:function(fueltype){
			this.fueltype = fueltype;
		},

		fueltype:'',

		getFuelType:function(){
			return this.fueltype;
		}

	};

	var myVehicle = evil.alloc(vehicle);

	var myCar = evil.alloc(car, ['unleaded']);

		log(myVehicle.isRunning());

		myVehicle.start();

		log(myVehicle.isRunning());

		log('Car:‘);
		log(’fuel: ‘+ myCar.getFuelType());
		log(myCar.isRunning());

		myVehicle.start();

		log(myCar.isRunning());

(more…)

I stumbled across this widely linked post about arrays in javascript. The author, who I believe is generally well respected in the webdev world, goes on about how you shouldn’t use arrays in JS as hash tables, because an array in JS is just an extension of object. Now, clearly, the Array() constructor is generally to be avoided for the reasons noted in the article.

However, if you use var myHash = [] in any world other than prototype, you will be able to happily use it as a hash table, because it is an object and in javascript objects ARE hash tables. So sure, creating a var as an array doesn’t strictly mean anything if you are using it as a hash table, but I think it is actually good practice, because when a developer sees a variable declared as [] they generally expect it to be an array or a hash of key=>value pairs. I just don’t really see the problem here.

Maybe on his team the author would rather use object literals for hash tables. Fine, but that doesn’t make it harmful to declare an object as an array and populate it as a hash. Further, in the comments several people seem to complain about for…in, which is totally insane because it is the only form of object reflection available in javascript! Its completely essential. I suppose people just need to be careful about “considered harmful” articles, because in a flexible, dynamic language you can do whatever you want. Some things might be slower, something might be worse practice in most cases, but its a flexible language, use it how you like.

Once you get past the basics of Javascript managing the “this” keyword becomes more and more complex. For me, when writing object-oriented js, I often find it frustrating that methods are loosly bound to their objects. So If I pass a function pointer to somewhere else it is impossible to determine what object that pointer belonged to, because “this” might refer to a different scope.

I hacked together a very ugly solution to this problem:

    function scopeChange(func, obj){
        obj.temp = func;
        return function(){
            obj.temp(arguments[0], arguments[1], arguments[2];
        };
    };

Now, this is a crappy solution, because it breaks with too many arguments and it also creates a pretty ugly closure. Now, luckily I ran this by some people, and it turns out there is a much better way to do this, the “apply” method of the function prototype in javascript allows you to execute a function in the scope of a passed object. So the new “scopeChange” funciton will look like this:

    function scopeChange(func, obj){
        return function(){
            func.apply(obj, arguments);
        };
    };

Much nicer! Now how did I get this far in life without knowing about function.apply?