Comments on: Cobra: A Little JavaScript Class Library

By: justin

justin — Sat, 24 Jan 2009 06:58:03 +0000

You probably would want to use another library in addition to this. It plays nicely with other libraries, even ones that already have a “Class” object (you just need to refer to Cobra.Class instead). I like MooTools when I don't need ExtJS, but everybody else seems to love jQuery.

By: Dave

Dave — Fri, 23 Jan 2009 08:05:50 +0000

This looks awesome. Crescendo needs some work for the web client, so there's a distinct possibility of using Cobra for that. I think it has a lot of potential, you definitely nailed down something that's been needed for awhile without the bloat of a huge framework.

Nice work.

By: justin

justin — Wed, 21 Jan 2009 03:47:43 +0000

I thought about both things and eventually decided against.

I wanted __extends__ to be a member of the class declaration so that it's explicitly clear what is going on. There's no concept in JavaScript that would imply that by passing a different class as the first parameter should create a class that inherits from that parent class. Any such implication is derived from how other languages do things. Thus, to avoid any possibility of confusion, I explicitly label the parent class.

I also thought about getting rid of "new". In fact, I got rid of it before deleting all that code and leaving it in. There are a few reasons to keep new.

1. This is JavaScript. A new instance of a class is created by using the "new" keyword. I did not want users of classes created with cobra to be forced to alter how they use JavaScript.

2. I want there to be one (and only one) obvious way to instantiate classes. It's easy to make the "new" keyword optional, but then you have two ways to instantiate classes. The way I have it, there is one way, and that one way is obvious.

3. More code. The first two reasons are pretty good I think, so why write more code to support a feature that is not necessary?

By: justin

justin — Tue, 20 Jan 2009 02:17:23 +0000

There is a reason for the underscores. The underscores indicate “this is special, and the system will do something different with this parameter”. I'm all for other suggestions, but I would like to maintain some sort of visual differentiation between normal attributes and “special” attributes.

I'm a python developer, not a ruby developer, so init's going to be sticking around .

By: John Long

John Long — Sat, 17 Jan 2009 22:53:27 +0000

This is nice. Please consider dropping the underscores on init and extend. Also Ruby developers like me would prefer initialize to init. Great work.