GOODS OO Database
But if what you want to do is store and retrieve objects, then an OO database is, at least in some cases, the most appropriate tool. We all love garbage collection in ram (well - I do anyway!), why not let it take care of your persisted objects? And who would say no to the database automatically upgrading accessed objects when your class gets new or different instance variables?
While it's not quite with the theme of the intended use patter of GOODS, I'm going to play with Pogo - a Perl API for GOODS. Unfortunately I don't yet have it compiling on Mac OS X but it compiles fine on my Linux box.
One of the problems with mapping a Perl or Ruby class to an OO database is that we can't reliably introspect the instance variables (let alone their type). I'm not quite sure how to handle that yet - whether there should be an API to make promises about your object. Another problem is that variable types aren't fixed. The biggest of this class of problem is that, especially in Perl, it's not uncommon to be able to use an object or a primitive (string etc.) interchangably eg. you might provide an URL object that can be used like a string in string context, but in reality it's a reference to an object - ideally we'd like the whole object to be stored.
Being more Smalltalk like Ruby may be better suited, but unfortunately there's no Ruby bindings for GOODS and I don't have the time or the in-depth understanding of the Ruby object internals to pull that off right now. There are a few references to a (now defunct) source forge project ruby-goods, but sourceforge's CVS archive shows no files.
I'll keep you posted!
02:21 AM, 14 May 2007 by Mark Aufflick Permalink