1.0 Release and Final Classes

I've just pushed the latest code that's been sitting on my laptop.  The exciting news is that after about six years of development, I'm finally preparing the 1.0 release!

I wanted to be announcing this about four years ago.  There have been a number of reasons that I delayed it for so long, all coming down to some level of perception that the language "wasn't ready" for a 1.0 release.

You could still argue that it's not ready.  There are a lot of things that the language lacks.  But the 1.0 designation was never about indicating completeness.  It was a promise of stability.  1.0 means that we won't break compatibility - your 1.0 code should continue to run until we release 2.0.  This doesn't matter much to the world at large, Crack doesn't have a lot of users.  But it does matter to me.  I use the language quite extensively, and I don't want to have to fix all of my projects when I make changes.

It also matters to me in a very personal way.  I've been working on this for a long time and I want to move on to other things (not that I'm abandoning Crack, quite the contrary, I plan to continue to use it and I'm already experimenting with ideas for the next major version).  I have a personal need for closure on this project, and this 1.0 label does that for me.

In the interest of ensuring compatibility, I've started work on one more feature which may or may not make it into 1.0.  The "FinalClasses" branch contains a set of changes to allow the @final annotation to be used on classes.  Final classes in Crack are similar to final classes in Java: you can't inherit from them.

The reason this change is important for 1.0 is because it lets us reserve classes in the standard library for future enhancements without breaking compatibility.  After 1.0, we can't add public or protected members to non-final public classes, because it is possible that users have derived from these classes and introduced their own members whose names would collide with those of the standard library classes.

The only problem is, at this point I'm not sure I care to delay the 1.0 release for this.  I still need to audit the entire standard library and add @final to all of the appropriate classes.  There's also the possibility that the feature may be buggy.

The alternative to introducing final classes is to simply accept that there won't be any new member additions to the standard library classes.  We can still add new functionality, but it will have to come in the form of new classes, which will likely be final themselves so they won't have this problem.

I'm going to weigh the arguments for and against final classes over the weekend.  On Monday, I'll either release 1.0 or delay it for a week or two while I make much of the library classes final.  But either way, there will be a Crack 1.0 release in February.