Lately, though, we’re beginning to realize that we didn’t quite go far enough. Memory issues have long plagued JavaScript developers. Because the garbage collector is opaque to the developer, and nothing like “finalize” is provided by the language, programmers often find themselves in situations where they are forced to hold on to an object reference for too long (or forever) creating a memory leak.

Just as we’ve done before, when we tackled this problem we decided to look at what has worked in the past. Finding inspiration in the elegant simplicity of C, we knew we’d found the right solution. And so, we’re pleased to announce the immediate availability of a manual memory management system in Cappuccino.

A lot of Cocoa developers disparaged garbage collection when it came to Objective-C, and we’ve come to realize they were absolutely right! Why rely on machines to solve problems for us when we can do it by hand. So, we’ve taken the Cocoa reference counting system and implemented it in JavaScript. We’ve replaced the existing no-op -retain, -release, and -autorelease methods with fully working implementations. When an object’s release count reaches 0, the object’s dealloc method will be called, and the memory will be able to be reclaimed. Now you have a clear way to clean up unwanted references when an object is no longer being used. Just make sure you do your reference counting correctly!

To do this right, we’ve created a global object table. These objects aren’t going anywhere on their own! If you don’t release an object, it will stick around forever, ensuring you’ll always have it when you need it. This global table acts as a lookup table for any object, allowing us to finally implement pointers in JavaScript. Since $ has become the coolest way to do completely non-standard lookups in an almost indecipherable way, we thought we’d jump on the bandwagon. Pass any pointer to $ and you’ll get the associated object! How do you get a pointer you ask? $$ of course! For example:

var o = [CPobject new]; // +new returns with a retain count of 1!
var p = $$(o); // returns a pointer to o

o === $(p); // we dereference the pointer and get the right object!

Zombies come standard, too! Just set OBJJ_ZOMBIE_DETECTION to true and objj_msgSend will throw an exception if you ever message an object that’s been dealloc’d.

We’ve even take the time to properly -autorelease all objects returned from class methods in Foundation, but we’ve made absolutely no effort to properly retain those objects in Cappuccino code that uses them yet. So we need your help. Every line must be scrutinized (but we shouldn’t to automate this process, as it would surely be too error prone). Rather than focus on developing new features or fixing bugs in the issue tracker, we hope that all Cappuccino contributors will spend their time writing memory management code so that we can fully realize this web development revolution!

We’ll be including these exciting new features in a future release, so you should get started adding manual memory management code to every single line of Cappuccino you’ve ever written! In the meantime, check out the working code on Github.

Please note this is an April Fools joke!

Atlas is a visual development tool for creating web applications using the Cappuccino framework. The best way to explain Atlas is to show it:

Think Vitamin has an article discussing Atlas in more detail.

We’re really excited about the ways Atlas could change the process of developing web applications. Atlas will allow developers to worry less about boilerplate user interface and glue code, just as the Cappuccino framework gives developers many common features expected by users, letting them focus on the ones specific to their applications.

Furthermore, Atlas allows non-programmers, such as many graphic designers, to join in on the process of actually building an application, rather than just providing mockups that must then be replicated in code by a developer.

Atlas will be available this summer. Sign up for updates on 280atlas.com and we’ll let you know of the progress on Atlas.

Now, this is usually the point at which someone chimes in that JavaScript is perfect, and that I just don’t understand it (you know, despite the fact that I’ve been using it for upwards of 10 years and have worked on its implementation in a major shipping browser). However, I think most people in the community can agree that there are some pretty big holes remaining in JavaScript. JavaScript is being used in increasingly larger projects, and in these projects some of its weaknesses are beginning to show. This is precisely why we have things like the (now dead) ECMAScript 4 proposal, Harmony, and Adobe’s ActionScript. And the truth is, had JavaScript 2.0 come around and been widely implemented and supported, we would have built Cappuccino without Objective-J. But the problem is that JavaScript 2.0 didn’t come around. I started working on what would eventually become Objective-J and Cappuccino three years ago, and in that time there have been no significant improvements or changes to the JavaScript language. Yes, certain browsers have taken it upon themselves to add a few nice features here and there, but for people writing real applications that need to run on most browsers, its simply not practical to rely on them. For the most part, we’re writing the same JavaScript today (language-wise at least) that we were 5 years ago. And that doesn’t seem like its going to change anytime soon.

Everybody is writing “abstractions” around JavaScript

And I don’t just mean projects like Pyjamas and GWT. I mean EVERYBODY, including Prototype, Dojo, and jQuery.  Yes, you read correctly, all the major JavaScript frameworks are essentially doing the same thing we are to some degree or another — we’re really not that original. The sole difference between their approach and ours is that when they add new language features to JavaScript, they’re not taking the extra step of introducing new syntax. Don’t believe me? Take a quick look at an example right out of the Prototype tutorials:

// when subclassing, specify the class you want to inherit from
var Pirate = Class.create(Person,
{
     // redefine the speak method
    say: function($super, message)
    {
          return $super(message) + ', yarr!';
    }
});

What we’re seeing here is the introduction of classical inheritance to the JavaScript language. This has always traditionally been a language feature, but due to its absence in JavaScript, the folks at Prototype have chosen to make it a library feature. The important thing to realize here is that it requires as much work to learn about the Class function as it would to learn about a new class keyword. And the same is true of Dojo:

dojo.declare("Employee", Person,
{
    constructor: function(name, age, currentResidence, position)
    {
          // remember, Person constructor is called automatically
          this.password="";
          this.position=position;
    },
    login: function()
    {
          if (this.password)
               alert('you have successfully logged in');
          else
               alert('please ask the administrator for your password');
    }
});

Once again, dojo.declare might as well be a new keyword since its shoehorning classical inheritance right into JavaScript. The jQuery UI widgets do something very similar to this with the “widget” factory method:

$.widget("ui.sortable", $.extend({}, $.ui.mouse,
{
    _init: function()
    {
           var o = this.options;
           this.containerCache = {};
           this.element.addClass("ui-sortable");
//...

At the end of the day, it doesn’t really matter if you’re a JavaScript expert, all these libraries have quite the learning curve and if its your first time with any of them, you’re going to have be referring to documentation a lot. And that’s not a bad thing. My point is simply that in JavaScript, more so than anywhere else, libraries need to first define what is essentially a new mini-language before they can begin to do anything useful.  This is a bit unfortunate, because it ends up tying language additions to library features, despite there being no necessary connection between the two. This makes it particularly hard to use the different libraries together in an efficient way. Sure, you can use all three in the same project, but there are some clear walls between them since each one decides to do classes a little bit differently. Not to mention the fact that you now have pretty redundant code your site. This is what happens when a language is clearly missing features. Individual frameworks in the .NET, Objective-C, Java, and so forth world don’t suffer from core incompatibility in the way they choose to do something as fundamental as defining class hierarchies. This is part of the reason we built Objective-J as its own standalone entity.  If all you want is some of the cool language features that Objective-J adds (without any of the design patterns in Cappuccino) then you can just use Objective-J, there is no “all or nothing” contract.

OK, so how is Objective-J different?

As we’ve now seen, there is a general tendency to add language features to JavaScript. Now, in my personal opinion, I prefer language features as fundamental as these to be part of the syntax, not part of a library. Let’s look at what Objective-J inheritance looks like:

@import "Animal.j"

@implementation Snake : Animal
{
    Number miceEaten;
}

- (String)speak
{
    return "hisss!";
}

@end

To me this code reads a little more naturally, and at the very least it’s no harder to pick up than the numerous library functions required in the other libraries. This approach also has the added benefit of making it absolutely trivial to write new syntax modules so that my text editor of choice can actually know what is going on in my code. You’ll also notice that creating a new syntax gives us great flexibility and allows us to add a few nifty features that wouldn’t otherwise be possible, such as optional static typing and code importing. But again, this isn’t as “out there” as some people would have you believe. It has even more benefits as we’ll soon find out, but before we do, let me answer the question that I’m sure many of you are asking right now:

Why Objective-C style syntax?

Again, we didn’t start off saying “lets port Objective-C”!  In fact, our first versions of Objective-J looked very similar to Java or C++:

class Snake extends Animal
{
    Instance.speak = function()
    {
          return "hisss!";
    }
}

However, this approach had some serious issues. To better understand them, we have to take a look at what the principal design goals of Objective-J actually were:

1. First off, it had to be a strict superset of JavaScript – meaning all existing JavaScript had to work. Believe it or not, we do like JavaScript, and we didn’t want to break it or create a trade-off of features.  Not to mention we wanted the existing plethora of libraries to still work.
2. Secondly of course, we wanted to add a number of “key” features.  Some things as crucial as being able to import code and built in support for classical inheritance.  We also wanted some features inspired by languages like Ruby, such as method_missing.
3. And lastly, we wanted to keep the ease of use of JavaScript, which meant not adding an extra “compilation” step, but instead allowing developers to still pound out some code and hit refresh and see it run.

The problem with adding language features in a way that would be more “familiar” to most developers, like the Java approach above, is that it would break backwards compatibility with existing JavaScript. This is because a lot of the keywords we wanted to use are actually reserved words in JavaScript, despite not being currently used. There is good reason for this though, because at some point they may actually mean something, and we wanted to make sure Objective-J kept working when JavaScript (finally) got a real update. Of course, we could have just chosen different keywords, like “Class” instead of “class” for instance. This however also breaks backwards compatibility because someone may have used the Class identifier in their code already.

The other problem with this approach is that it made it next to impossible to add harder features like optional static typing or dynamic dispatch of methods (thus allowing for method_missing) without having a full blown compiler. There’s no way to “intercept” a method call in JavaScript.  So once again, we were stuck.

Luckily for us however, a group of people ran into these same issues about 25 years ago when trying to improve the C language. These were the folks at Stepstone who developed Objective-C. Just like in our case, Objective-C had to be a strict superset of C (unlike C++ which does NOT always play nice with C). Also lucky for us is that JavaScript syntax is very close to C syntax, so their language additions translated very naturally to JavaScript. And perhaps now it is obvious why our keywords start with the “@” symbol, because in this manner there is no possibility of ever clashing with future JavaScript keywords or predefined user variables and functions. In other words, we can now add to the language as much as we want without the fear of breaking compatibility with existing JavaScript.

Similarly, the new method passing syntax allows us to have firmer control of how messages are sent:

object.jsMethod();
[object objjMessage];

This is the famous bracket syntax. What you may not realize is that this makes it perfectly clear when you are using Objective-J style message dispath, allowing us to “hook in” and add things like method_missing, etc. There are a whole bunch of other cool things that this enables which are outside the scope of this post, but I encourage you to check out the other tutorials on our site to learn about them. All this, without breaking any existing libraries and without requiring the user to compile before every run. Pretty impressive for a langauge that is supposedly “completely different” from JavaScript.

The Part About Leaky Abstractions

On top of Objective-J, we’ve built the Cappuccino framework, which is designed to help developers write desktop class applications on the web. One of the many things Cappuccino does is “abstract away” the DOM, and I’ll get into why we do this in a moment.  But before I do, I think I should take a second to address this whole “leaky abstractions” business, because there seems to be a fair bit of confusion regarding this as well. If you haven’t already read it, or even if you have, I recommend you take a look at Joel Spolsky’s original article on the subject.

When people refer to this article, it is usually to criticize some “abstraction” because it will “inevitably” be leaky, and then oh boy you better watch out! But this was not Spolsky’s thesis. He didn’t end the article with “and thus avoid abstractions at all costs”. He was not somehow suggesting that we stop abstracting altogether. Quite the contrary, its clear that although these “leaks” are an unfortunate and unavoidable consequence, abstractions are still incredibly worthwhile: hence the conundrum. In every single example given in the article, it was never implied that the abstraction was somehow bad or invalid because of its leak: Just because certain SQL queries are slow doesn’t mean you should manually read in tab delimmeted files and scan them yourself. Just because TCP can fail if you unplug your computer doesn’t mean you should do IP transfers yourself.  It just turns out that, big surprise, nothing is perfect. Joel put it best himself:

Indeed, the abstractions we’ve created over the years do allow us to deal with new orders of complexity in software development that we didn’t have to deal with ten or fifteen years ago, like GUI programming and network programming.

And the truth of the matter is that the problem of leaks is overstated. I find it particularly hilarious when JavaScript programmers bring this up, since JavaScript, being a garbage collected dynamic interpreted language, is quite possibly one of the biggest abstractions of all. And yet, most of us can see that the benefits of JavaScript far outweigh the “leaks”. I think few JavaScript programmers have had to learn “the whole stack” once they’ve encountered one of JavaScript’s many leaks, whether it be performance issues (from being interpreted) or perhaps large memory consumption (from being improperly garbage collected in some browsers). No one has had to go and open up WebKit’s source code to figure out these problems. Most of the time you simply Google your concern and learn the workaround. Not that big a deal.

Leaks are just something we all have to learn to deal with in every facet of programming, because programming is abstraction. Abstraction is basically all programmers ever do, from pushing electrons across a wire, to turning C into assembly, to interpreting JavaScript in your browser, every step in computer science has been an exercise in abstraction. There is nothing inherently wrong with abstraction. I can understand if someone disagrees with a particular abstraction for well defined reasons, but simply waving your hands and referring me to the law of leaky abstractions is not a valid argument.

To suggest that we shouldn’t abstract because of Joel Spolsky’s Law that all abstractions are inherently leaky is to suggest that we shouldn’t debug because of Murphy’s Law that all code will remain inhrerently buggy.

Back to Cappuccino and the DOM

Cappuccino doesn’t just abstract away the DOM, it abstracts away HTML, CSS, VML, the JavaScript DOM API, etc. Why? Because as you can see there are just too many technologies with overlapping responsibilities. It’s never really clear whether you should create a button in HTML or in JavaScript code, and whether you should style it in a CSS files or apply styles manually in JavaScript, or whether you should just use Canvas to draw everything. Not to mention that on top of having to sort through all these technologies, you have the additional challenge of having to accomodate for every slightly different flavor that exists in every browser. Sometimes its relatively simple, but othertimes it can be quite complex, as is the case with Canvas and VML. The other problem is that these technologies were simply not originally designed to handle the tasks they are now performing.  HTML was designed for laying out documents, not creating applications.

We look at these technologies completely differently.  To us, HTML, CSS, Canvas, the DOM, etc all represent the “rendering engine” of the web, in the same way that graphics cards are the rendering engines for your computer. It’s too difficult to learn the intricacies of every graphics card on the market, so developers instead use technologies that hide these details like OpenGL. In the same way, Cappuccino defines a common way to “draw” for the web. Internally, it figures out whether its more efficient to make a div, or draw to a canvas, or use VML. This is a fantastic time saver today, because it allows Cappuccino to worry about things like performance and allows you to just get a button on the screen. But its going to be even better as time goes on. This is not only because the underlying code will get better, but because web applications today look like this:

But tomorrow, when enough browsers finally support SVG, they may look like this:

Or, for all we know, like this:

The important thing is that when this happens, and it will eventually happen, people who invested heavily in todays technologies will have to spend a great deal of effort updating, but we will just swap out the guts of Cappuccino and your code will inherit the benefits of SVG or whatever new technology is out there.

Conclusion

To me what we’ve done with Objective-J and Cappuccino seems inevitable. Even the most conservative major JavaScript libraries can’t get away without adding features to the language, and we’ve simply taken the next logical step with Objective-J. Similarly, Cappuccino is a tool that allows you to stop thinking about web pages and browser incompatibilities, and instead focus on the complex problems presented by the challenge of creating full-on applications on the web. As we’ve said countless times, Cappuccino isn’t for everything. All of this abstraction isn’t necessary if you’re simply trying to add dynamic elements to a site like bankofamerica or digg. Cappuccino is for building rich applications in the browser, a small minority in the web world today. We believe that this is where things are headed, and we designed Cappuccino specifically to get us there.

- Francisco

Accessor synthesizing adds a new keyword to the Objective-J language, @accessors. When declaring your list of ivars in the @implementation block of your class, adding this one keyword will tell the Objective-J preprocessor to implement accessors for you. Let’s see an example of a simple class written using the old method, and then the same class using @accessors.

This Person class has two ivars, firstname and lastname. Before @accessors, the class looks like this:

@implementation Person : CPObject
{
    CPString firstName;
    CPString lastName;
}

- (void)setFirstName:(CPString)aString
{
    firstName = aString;
}

- (CPString)firstName
{
    return firstName;
}

- (void)setLastName:(CPString)aString
{
    lastName = aString;
}

- (CPString)lastName
{
    return lastName;
}

@end

Using the new @accessors keyword, we can eliminate four methods:

@implementation Person : CPObject
{
    CPString firstName @accessors;
    CPString lastName @accessors;
}
@end

This second version is much more succinct than the first, and less tedious to program. We think this will be helpful for developers, and will increase productivity and code readability.

It’s important to note that this doesn’t change the way you use a class. For our Person class, in both cases, the code for getting the first and last names of a person (in the myPerson variable) would look something like this:

var fullName = [myPerson firstName] + " " + [myPerson lastName];

Similarly, setting an ivar looks like this:

[myPerson setFirstName:"Winston"];
[myPerson setLastName:"Smith"];

Like any key-value-coding compliant class, the name of the instance variable becomes the “property” or “key”, and that key name is used in the setter and getter methods. If your key is firstName, the getter for that key will be firstName, and the setter will be setFirstName:. The same pattern applies to any other key.

Configuration

There are a few configuration options when using the new @accessors technique. Perhaps most importantly, is the ability to change the name of the property. For example, if you declared an instance variable like this:

CPString _location @accessors;

Objective-J would generate two accessor methods called _location and _setLocation:. These are the expected accessor methods for a key called “_location”. In order to generate more friendly versions without the leading underscore, you can modify your declaration like this:

CPString _location @accessors(property=location);

The addition of the property=location tells Objective-J to use “location” as the new property name, instead of “_location”, which will generate location and setLocation: methods without the underscore. In addition, you can also specify the specific name of both the getter and the setter method, like this:

BOOL _hidden @accessors(getter=isHidden, setter=setIsHidden);

This code specified a boolean instance variable called _hidden; the getter method will be called isHidden and the setter method will be called setIsHidden:. One thing to keep in mind when specifying your own getter and setter method names is key-value-coding. Although we don’t yet have much documentation on the subject (you can read Apple’s documentation here), key-value-coding enables several important features in Cappuccino, so it’s important to maintain key-value-coding compliance. Normally, the rules are that for a given key, say “foo”, the getter is called foo, and the setter is called setFoo:. There’s an additional rule for boolean values, which says that you can use isFoo, and setIsFoo:, in addition to the usual method names. In our case, thats why our custom getter and setter names are still key-value-coding compliant.

There are two additional configuration options, readonly, and copy. By default, @accessors will generate both a getter and a setter. If you only want to expose a getter method to the world, you can add the readonly value in the arguments. The other option, copy, has to do with how the setter works. Normally, when you pass an object to a setter, it’s assigned directly. The generated setter looks like this:

- (void)setFoo:(id)aFoo
{
    foo = aFoo;
}

When you specify copy, the argument is first sent the message copy, and the return value of that message is assigned to the instance variable:

- (void)setFoo:(id)aFoo
{
    if (foo !== aFoo)
        foo = [aFoo copy];
}

This is useful if you want to ensure that an object you’re passing isn’t modified out from under you. Of course, it only applies to ivars that are both read and write, and cannot be combined with readonly. To summarize, you can use both of these options like this:

@implementation FooBar : CPObject
{
    id foo @accessors(readonly);
    id bar @accessors(copy);
}

History

Apple introduced properties in Objective-C 2.0, which added a new way to declare instance variables for your classes. The two key features were the ability to use what has become known as “the dot syntax” for accessing instance variables, and the second was the ability to have the compiler automatically generate accessor methods. Reducing code, especially code that doesn’t change every time you write it, is certainly a worthwhile goal, so we thought it would be a good idea to bring this new idea to Objective-J. There are a lot of things about the Objective-C 2.0 implementation of properties that don’t make sense for Objective-J, so we decided not to port them directly and instead developed a syntax that we believe makes the most sense.

The main goal we want to achieve is eliminating the need to write your own accessor methods. We don’t, however, support the “dot syntax” aspect of Objective-C 2.0. This makes the dual @property and @synthesize syntax of Objective-C 2.0 redundant. Furthermore, rather than just choose one or the other, we decided to use a new keyword, @accessors. This will lesson the confusion for existing Cocoa developers trying to learn Objective-J. It will also make sure we don’t have an incompatible syntax going forward, as we explore new ways to work with existing Objective-C code.

Conclusion

Accessor synthesizing will reduce the amount of boilerplate code that needs to be written, and make the language just a little bit easier to develop in. Overall, we think it’s a worthwhile addition to the language. If you have an opinion, we’d love to hear it, so sound off in the comments. Although this new syntax isn’t yet written in stone, we won’t expect to change it after version 0.6 of Cappuccino ships. Checkout the latest version of the git repository to start using this new feature.

We’re also considering other language features that might make it easier to program in Objective-J. If you’ve got an idea, or you’re interested in being part of the discussion, you should sign up for the mailing list, where we’ll be discussing some of the new proposals.