The Paper Crane and The Heavy Objects That Fell

"It is just like inventing the wheel, it has already been done!"
-- Someone...

Introducing SSTS -- The (Super) Simple Type System

So a few days ago I started thinking about GLib and GObject and wondered how easy -- or hard -- it would be to create my own base object system. So the first thing that every good hacker does when faced with such a question is to do it, from scratch, without looking at others code.

So after a few hours I had written my base object type with every function that I would ever need. Than the next day I wrote the first object derived from this base object. (Still not even compiled the code). On the third day I started writing tests and ironed out some compile errors, and than I wrote more tests (this time with the derived object type) and tested everything with valgrind and ironed out every memory leak I could find.

Than, I decided to write a new type, a Map... This is where I found out that all the plane sailing that I have had took an abrupt end, and I was faced with a non-trivial problem:

How do I discern a object that is of the type system from an object that is not? I need to be be able to call the objects destructor if it is, and ordinary free () if it was not.

This lead me -- after some non-help from G+ -- to dig though GLib/GObject C code only to find out that the problem is non-trivial. In GLib/GObject it seems that they use a lookup table to find out if an object is or is not of the type GObject.

Action plan:

There is two ways I could do this:

• The sane and hard way -- basically reimplementing what GLib/GObject does.
• The easy but mad way -- just ask the user for a destruction method/function as a parameter.

The first way would be the hardest to implement, and probably course trouble if I were to use GObjects somewhere. But if I do it that way the user of the library would have less work to do.

If I do it the second way it would mean less work, but the end user would probably not be so pleased to have to specify the destruction method for each map. I may even have to have the user specify it for every item in the map.

If I go with Plan A (The Sane, but hard way) it also solves other inheritance related issues: How to know, in large object hierarchies, what object is what type.

The lookup table would contain pointers to every object that is registered with the system (at run-time), during the registration of the object the object must tell the system what types it is (what objects it has inherited from).

The look-up list would have to have two fields per item: a key (the pointer to the object) and a value that is a list of object-types that the object is.

Any way: for those that are interested in this (Super) Simple Type System it can be found on launchpad.