ooc-dev team mailing list archive

[oliver daids <oddity007@xxxxxxxxx>]

This began as a sort of way to test ooc's almost dynamic-at-compile-time
feel, attempting to extend ooc's class system to allow an almost drop-in
patch for switching allocation methods.

I didn't want to just limit it to "gc or manual or xxx, not all", and I
figured that being able to supply an allocator wrapper to a class from which
it would allocate would make this easiest, I got that working.

However, I originally wanted to do something along the lines of SDL's RWops
system (or any abstract io system)

/////////////////////////////////////////////////////
allocator:=Allocator gcAllocator()       //gc would be default anyway
string:=ArrayList<Int> cloneWithAllocator(allocator) new()
//Due to type restrictions, ended up being implemented as
allocator:=Allocator gcAllocator()       //gc would be default anyway
string:=allocator cloneClass(ArrayList<Int>) new()
////////////////////////////////////////////////////

cloneClass would return a subclass of it's argument, allocated with
allocator, and having that class's super being it's argument and having it's
allocator set to allocator.
Any instances of this would increase the allocated class's reference count
(defaults at 1 for allocated classes and 0 for ones made at compile time,
which means it doesn't get freed), and when its last instance is freed (as
counted by the refcount) it would also be freed.  The Class alloc method was
changed to allocate with the allocator and __retain__ the class, it also had
a __release__ method which overrides Object's newfound __release__ method
which asks its class to release it (__releaseInstance__)

All of this would be done automagically, requiring you to simply clone the
class, allocate with it, and __release__ the instance if its allocator
mandates it.

This was the method I tried to do and got fairly far with it.  However, I
failed when I stumbled into the realm where ooc's
Magical-Mutated-Crowbar-of-C-Hackery lies dormant  (namely, its dependence
on the types in lang/types.ooc and their magical order).  I imagine if a
person who had deeper knowledge of the compiler tried, they could get this
working.

But this does leave me to ask:  How else would we go about this?  This is
definitely a major step towards making the sdk zero-gc friendly, while
allowing them to mix.

There are a couple ways to go about it, one is to supply the allocator as an
argument everywhere something is allocated.  Then there is the idea of
having it as a global state (not thread safe).  Most of this could be done
by simply patching the sdk.

The part that I managed to get compiling is located here:
http://gist.github.com/455203

Note that this does not include the modifications I made to lang/memory.ooc
or lang/types.ooc (such as adding malloc/calloc/realloc/free or the Object
and Class modifications I mentioned above), but this should help out if
anyone decides to actually add this to ooc.

I bring this up mainly as an idea, I'm not exactly sure how this concept of
abstract allocation may get implemented.