Build 4.0.31 API Changes

Hello 4coder users!

I am writing an update on the upcoming 4.0.31 because it's been in development for a _long_ time and there's a lot happening in this build now.

Since I opened the github issues page I've collected a lot of feature requests and bugs and that alone has been a big source for changes. On top of that there were the four 4coder J4MMs! (tm) that I did with Casey that led to some big shifts in the core organization and feature set. In addition to all of that, I had my own feature list for this build with upgrades to the history system, the UI system, and more built in listers. All of this combined has led to possibly the biggest single 4coder build I've ever made.

OS Changes

As I stated at the beginning of the year I am only planning on doing one OS at a time now, and there have been so many changes to the OS layer that this is looking like a really good call. File change notifications are getting completely reworked to guaranty correctness and to avoid interfering with some corner-case file system behaviors; keyboard coverage has been widely expanded; and I've added a regular wake-up timer; in addition to all of this there a major changes in the OS layer by virtue of the changes to my base allocator and string types which I will discuss more below.

API

There have also been major changes to the custom layer API. I have reconfigured it to work on IDs instead of "Summary"s; and it now explicitly uses the String type for both string input and string output parameters. To make this easier to adapt to I'm providing a "transition" helper file with this upcoming build that implements the old API on the new one as best as it can, everything in the standard custom layer is implemented on the new API now, so all a user has to do to update is disable the transition helper and rewrite any effected routines.

Allocators

That isn't the only big change that will break existing customization layers. I'm also switching off the old Partition linear allocator. This is a helper that was added to 4coder a long time ago, and I've learned a lot since then about how I would rather organize memory allocation. The new system is interesting enough to me to deserve it's own entire blog post some day, so other people can avoid the same mistakes in my old Partition system. I'm also thinking of changing off my Heap allocation system, although that isn't a sure thing yet. There is no transition helper for exactly replacing partition, but there are two new types called Cursor and Arena that are mostly capable of replacing Partition everywhere, depending on the situation.

Strings

There is yet another big change coming down the pipe for the API, which is a complete reboot of the String type and library. Just like with the allocator, I've had a lot of time since the original String type I wrote in 4coder to develop a string system that I prefer a lot more. The new string types are better at handling string building: the old system required either a fixed size array, or a fixed-size linear allocator (the Partition) and prevented intermixing string building with any other allocations on the allocator; the new system can avoid all of these limitations. The new system also supports ASCII, UTF-8, UTF-16, UTF-32 string types with conversions and an "Any" string type for encoding agnostic strings. The encoding feature isn't necessarily a big deal for users in the custom layer who usually only care about ASCII or UTF-8, but better support for these string types will help a lot in the Windows layer where UTF-16 <-> UTF-8 conversions are ubiquitous, and in the buffer processing systems where UTF-8 <-> UTF-32 conversions are common.

Unlike the allocator changes I believe that I will be able to supply a transition helper for strings, but I have to do more work in this direction to see for sure if that is the case.

Transition Helpers

Throughout the history of 4coder many builds have been API breaking in some small way, but with this build I am essentially trying to create the "final" API that will have to last forever, so I am not holding back from remodeling everything. The downside to this is that there will be a lot of work for users with big customization layers to update to this build. To make this transition easier I am keeping a document that lists everything I break, and I will write and release a guide to updating to the new API along with this build.

As I've mentioned throughout this post I've tried to maintain transition helpers that implement the old APIs on top of the new ones, but where I cannot provide such helpers I am hoping the guide will be enough. After this build comes out I expect I will spend a while just helping everyone with the transition before moving on to the next build.

The End

Alright I think I've now shared all the most important points. There are a lot of features in this build that I haven't gone over here, but those aren't really the bigger point. Maybe I'll make another post about that too. Thanks for your patience everyone while I work on all of this!