YUI 3.0 PR1
Yahoo pushed out their YUI 3.0 Preview Release 1 yesterday, borrowing some of jQuery’s DNA—chaining, compact, expressive code. Not a bad thing, I think.
- Edit Posted August 14, 2008 at 7:40 AM PST in JavaScript
- Leave a Comment
Yahoo pushed out their YUI 3.0 Preview Release 1 yesterday, borrowing some of jQuery’s DNA—chaining, compact, expressive code. Not a bad thing, I think.
Originally posted to ydnar.vox.com in November 2007.
...I added Mark’s blog as a favorite. Primarily because it’s awesome, and also because of his tagline about bacon. <3
To favorite someone’s blog, you’ll need Firefox with Firebug installed.
<!-- Asset Stream 6a00b8ea0717f31bc000b8ea0717f51bc0 -->
app.c.addAssetAsFavorite( { asset_id: "6aNNNN..." } )
Originally posted to ydnar.vox.com in February 2007.
Last week I was revisiting the always fun problem of implementing “classical” inheritance in JavaScript. I’d taken a few stabs at it, and had gotten it to a reasonably good state that borrowed some good ideas from Doug Crockford, Sam Stephenson, and Dean Edwards. Joshua Gertzen wrote a good post about various methods on his blog.
I’ve never been terribly thrilled with the form Class.superClass.method.apply( this, arguments ).
It was redundant: replicating both the class and method names. Copy
& paste of code could lead to subtle errors, and it’s annoying to
type that much. But the alternatives were worse: Recompiling the
function to generate a “magic” lexical for the superclass or wrapper
methods. So the Class object basically sat untouched for a year and a half.
Back to last week…It occurred to me that in all the JavaScript we’d built for Vox,
we almost never shared a method between two objects, except via
inheritance. There were a couple exceptions, but they could be
rewritten (it turned out to be a good idea anyway). Second, functions
are objects like everything else, and can have arbitrary properties.
Third, arguments.callee is available in every function
call in JavaScript. I realized then that storing the superclass was not
as useful as just storing the supermethod.
For any given method in a class, store its supermethod as a property of the method: method.__super. Instead of the unwieldy construct above, any method could simply use arguments.callee.__super.apply( this, arguments ).
The Class constructor from Core.js:
Class = function( sc ) {
var c = function( s ) {
this.constructor = arguments.callee;
if( s === __SUBCLASS__ )
return;
this.init.apply( this, arguments );
};
c.override( Class );
sc = sc || Object;
c.override( sc );
c.__super = sc;
c.superClass = sc.prototype;
c.prototype = sc === Object ? new sc() : new sc( __SUBCLASS__ );
c.prototype.extend( Class.prototype );
var a = arguments;
for( var i = 1; i < a.length; i++ )
c.prototype.override( a[ i ] );
for( var p in c.prototype ) {
var m = c.prototype[ p ];
if( typeof m != "function" || defined( m.__super ) )
continue;
m.__super = null;
var pr = sc.prototype;
while( pr ) {
if( defined( pr[ p ] ) ) {
m.__super = pr[ p ];
break;
}
if( pr === pr.constructor.prototype )
break;
pr = pr.constructor.prototype;
}
}
return c;
}
arguments.callee was useful in the constructor too: Instead of creating a circular reference by overriding the constructor like this: constructor.prototype.constructor = constructor, the constructor itself can just set it on the this object when the constructor is called: this.constructor = arguments.callee.
Calling a supermethod can be simplified further, to arguments.callee.applySuper( this, arguments ) via a little sugar:
Function.prototype.extend( {
applySuper: function( o, args ) {
return this.__super.apply( o, args );
},
callSuper: function( o ) {
var args = [];
for( var i = 1; i < arguments.length; i++ )
args.push( arguments[ i ] );
return this.__super.apply( o, args );
}
} );
Originally posted to ydnar.vox.com in November 2006.
Adobe has given the Flash ActionScript (ECMAScript or JavaScript 2.0) interpreter to the Mozilla foundation as the new open source core of SpiderMonkey, the JavaScript engine for Firefox. It's called Tamarin. Brilliant.
Both Mozilla and the Webkit folks fixed the bugs I noticed with their <canvas> implementations. It was pretty nice to see someone make a Doom-style renderer using the same method I had been attempting at the time.
...or why they can't work the way I want them to.
I was reading Simon Tatham's brilliant essay on Coroutines in C the other day after hunting around to see if anyone had implemented continuations in JavaScript. This is a jumbled account of how I came to want and fail to make them work (yet).
Continue reading Continuations in JavaScript