Tuesday, February 17th, 2009

Xopus Application Framework: Objective-J Done Different

Category: Framework, JavaScript

The good folks at Xopus (the really cool browser-based XML editor) have been working largely in silence on a new version of their application. They’ve recently posted a presentation that talks about the framework behind this new version of Xopus.

In the linked PDF, the framework is revealed to be an “object-oriented ‘extended subset’ of JavaScript”, much like Objective-J, but while Objective-J brings a syntax very similar to an existing language (Objective-C), the Xopus framework brings its own syntax to the game:

  1. Package("com.xopus.code" );
  3. Import("com.xopus.code.Food" );
  4. Extends("com.xopus.code.Animal" );
  6. Class(
  7.     function Monkey (name) { this.name = name; },
  8.     function getName () { return this.name; },
  9.     function favorite () { return new Food("banana" ) ; },
  10.     Static, function kind () return "chimp" ; }
  11. );

Among the features of the Xopus framework are:

  1. Hierarchically structuring programs into packages
  2. Some forms of program veri?cation
  3. Making dependencies explicit
  4. Dependency resolution
  5. Consistent ?le-system layout
  6. Server side compilation to ?attened form
  7. Serving the client efficient and possibly obfuscated code
  8. Preserved stack trace for easier client-side debugging
  9. Inheritance
  10. Annotations, including visibility (public, private, protected), static, continuation, test, deprecated, API–they are used for documentation and compilation and stick around at run-time for reflective access

The server-side compiler is presently based on SpiderMonkey; the compiler is entirely written in JavaScript and includes “extensions for profiling, coverage, and dependency visualization.”

Unit Tests

Unit testing is baked into the class format, as in:

  1. Class(
  2.     function ArrayUtilTest() { this.TestCase(); },
  3.     Static, function () { new ArrayUtilTest().start(); },
  4.     Test, function last()
  5.     {
  6.         var obj = {};
  7.         var arr = [1, 2, 3, obj];
  8.         this.assertTrue(
  9.             "last() should return the last value in the array",
  10.             arr.last() === obj);
  11.     }
  12. );

The PDF also shows screenshots from the framework’s unit test runner as well as a continuous integration server.

While the bits aren’t yet available (that we can tell), forgive us for posting about it anyway–it sounds really interesting.

Posted by Ben Galbraith at 11:00 am

2.8 rating from 24 votes


Comments feed TrackBack URI

There are so many ways to add classes to JS that it’s dizzying. My chief concern: who else will be able to read your code?

That said, I like the looks of Joose, and Objective-J is creeping up my radar as I learn Objective-C for the iPhone.

Comment by Nosredna — February 17, 2009

There are so many ways to add classes to JS that it’s dizzying.
It’s a shame that few Class implementations keep an eye on whats planned for ES3.1+.

Comment by TNO — February 17, 2009

Assuming you buy into the idea of compiling to JavaScript, this appears to be a very well thought-out approach. I love-love-love the idea of coding annotations to be removed by the compiler. You can use it for conditional compilation, testing, profiling, coverage, and, of course, documentation. And they claim to have hit all these sweet spots – bravo!

I’m not crazy about the way they ask you to express method modifiers:

Static, function() { ... }

A slight change in formatting renders this syntax well-nigh unreadable, IMHO.

Comment by whylom — February 17, 2009

@ whylom: You have! It’s right on the page you’re linking to. :-)

Comment by PieturP — February 17, 2009

I hate to be the one to say it, but why? “Compiling” javascript from a mess into a larger mess seems like a major step backwards in terms of readability and reusability for future projects.

“Keep it simple stupid” comes to mind when I see some of these projects.

Comment by pplante — February 18, 2009

> Some forms of program veri[fi]cation

Sounds interesting. Did they implement soft typing?

> Inheritance

The feature everybody is missing. :)

Comment by chiaroscuro — February 18, 2009

Disclaimer: We have no plans to release XAF. This blogpost was just meant for inspiration and sharing of knowledge. Feel free to contact us if you want to know more.

> It’s a shame that few Class implementations keep an eye on whats planned for ES3.1+.

We wanted the uncompiled code to be syntactically correct Javascript. This allows us to have any off-the-shelf Javascript engine parse our code and run the compilation. In fact, if we don’t use the serverside compilation step, the code will compile itself in the client (which takes much longer due to HTTP overhead). So we couldn’t defer from what browers understand today.

> who else will be able to read your code?

The flexibility of Javascript can easily lead to unreadable code, we think having a framework and the code guidelines that go with it make our code more readable. Our newest team member can confirm that.

Also keep in mind that it still is Javascript syntax, so you can use what you’ve learned elsewhere. And we can take the code and embed it in another code base (which we do when we backport code to Xopus 3).

> “Keep it simple stupid” comes to mind when I see some of these projects.

We feel we have kept it as simple stupid as possible. We have not written our own parser for instance. But with the metrics of our product we need at least packages, namespaces, dependency checking, (multiple) inheritance, event handling and unit testing. We found no other framework that could give us that. (We currently have 600+ classes in 180+ namespaces, 1300+ handcrafted unit tests, 3K+ generated unit tests, 2.1MB of code which compiles to 2.5MB of Javascript which is obfuscated to about 900KB when shipped.) We have tried to take Plain Old Javascript as far as possible for about 7 years, but it reached its limits. We are now using XAF for almost 2 years and it works very well for us.

> Did they implement soft typing?

Yes, we can have the compiler add runtime type checks at development time which will be omitted in the shipped code.

Comment by Laurens — February 18, 2009

Leave a comment

You must be logged in to post a comment.