Java-like Object-Oriented Code in Javascript
[extremely edited - I originally had a very detailed post here about a javascript library I just released. I realized that that amount of detail deserves a more static page than a blog entry, so I moved the details out of this post (to a page created through the blog software because I’m lazy 
)]
Javascript is a very loosely-typed and dynamic language. Variables can be of any type, function parameters can be of any type, and properties of objects can be added and removed at runtime. This can be very useful in many situations, but it can also create some pretty nasty messes that are a nightmare to maintain. Sometimes more rigid structuring is needed.
There are several techniques and libraries available for creating object-oriented Javascript that support inheritance, but they usually involve some difficult-to-read syntax and fail to provide other object-oriented features like abstract methods and interfaces. My goal is to create a Javascript library that provides many of these features and eases the pain of developing complex javascript solutions. My first step towards that goal is the initial release of The $class Library (as of this posting, I’ve actually made one change since the initial version in response to the first comment).
The $class Library will be improving as I receive feedback. Check it out and tell me how it could be better (I already know the file could be smaller; I’ll work on that soon).
June 3rd, 2006 at 11:28 pm
In order for the abstract method feature to be truly useful, I do think you need to check conformance at compile time (or the closest thing in javascript, class creation time). It shouldn’t be hard to determine whether a class has abstract methods; just count them when the class is defined, and store the count. When you inherit from an abstract class, with each method you add, check to see whether the base method was abstract, and if the new method isn’t abstract, decrement the count for the new class. Only classes with an abstract method count of zero can be instantiated. When inheriting from abstract classes, the programmer needs to find out as soon as possible if something’s awry.
It’s nice to see someone demonstrating the full extent of what can be done with javascript. You definitely have the right approach — make something useful, and then make it better. Good luck with it. I’ll be happy to keep tossing in my few cents.
Ben
June 4th, 2006 at 12:25 am
Thanks, Ben. Every couple of cents helps
.
I actually did have abstract implemented like that at one point. If you tried to instantiate an abstract class, an exception would be thrown with a message that listed the abstract methods and in which class they were declared. I ended up removing that constructor-time check to reduce overhead. I think I will put the constructor-time check back in with new plans of eventually having 2 versions of the library: a development version with all the error-detection that will make development easier, and a stripped down production version with minimal error detection to reduce the file size and run-time overhead.
Any thoughts on if/when it is appropriate for static properties to be inherited? I’m thinking it makes sense for interfaces to inherit statics from other interfaces that they extend, but I’m second-guessing my decision to have classes inherit statics from the interfaces they implement (but I think that’s how Java works). If I continue to have classes inherit statics from interfaces, I should probably also make classes inherit statics when they extend a class.
November 5th, 2007 at 9:58 am
[…] read more | digg story […]