Development cycle using GOODS for persistence

John Pierce john.raymond.pierce at gmail.com
Tue Oct 19 14:00:19 UTC 2004


Hi all,

> > It would be possible, and useful, to do much more sophisticated things
> > than this.  Each object in the database knows exactly what the layout
> > of its class was at the time it was stored, so that you could in theory
> > set things up so that every time an object is loaded, it goes through a
> > transformation defined for the specific old/new class layout pair
> > that's relevant.

Why couldn't we invent a way to store classes in a database (or
externally) as well?  I've been asking this question (rhetorically)
where I work for a while and was curious if anyone has done some work
like this?

> This is exactly the approach that Magma takes, or *tried* to anyway, by the
> user specifying an "upgradeBlock" that implements a transformation that are
> supposed to occur version-to-version.

Providing upgrade blocks or conversion strategies always seems to be
the only option ever presented (even if that option is not
implemented).

While, I think, that this is a noble approach and often what I am
looking for, I am very curious these days as to what kind of enabling
characteristics we'd pick up if we could also *store* the classes in
our databases and external systems.

Imagine a copy-on-right concept where instances of Foo class are
stored in the database (say GOODS).  Additionally, because you cannot
tell when the Foo class will be modified you also squirrel away a copy
of Foo class in the database (called Foo sub 1).

When loading instances of Foo from the database at some point in the
future, if Foo sub 1 still equals Foo in the System Dictionary, then
these instances just become instances of SystemDictionary at: #Foo.

On the other hand, when loading instances of Foo from the database at
some point in the future, if Foo sub 1 no longer equals Foo in the
System Dictionary, then Foo sub 1 is reconstituted (but not loaded in
the global System Dictionary??) and the Foo instances become new
instances of this nameless Foo sub 1 class.

I guess equality between classes could be defined as their instVars
(shape of class) are identical (or compatible).  I'd also probably
include comparison of the method dictionaries in my definition of
equality and if behavior has changed then the classes are no longer
equal.

At this point I am less concerned about exact definition of equality
here -- it could be a loading strategy applied by the developer in a
specific situation that suits his purposes.

Anyways, I have this notion in my head that *not* having to migrate
instances of objects every time we change classes could be a very
enabling development mode to be in.

We currently use GOODs and our own rolled instance-storing strategies
right now and I find that I *always* must consider migration before
doing too much work in the class browser.

I am not against migrating to the latest edition of a class, but I
just want a separation of concerns.  I want to migrate instances at my
pace, not the system's pace.

Lastly, I think this way of thinking about it would enable a property
of OO that Alan Kay talked a lot about.  That is, that an object
should be a self-contained little machine that knows how to operate
autonomously.  This cannot be done right now with our traditional
instance storing strategies since we do not store the behavior side of
the fence anywhere but in our images and SCM systems.

This is breaking encapsulation and, whether I am just day dreaming,
and you all say this *cannot* be done for whatever reasons, I still
like to day dream about that vision of Kay's and I don't think this
could be a terribly difficult idea to bake into Squeak.  Just a hunch
of mine, but I've not had time to tackle it yet.

Any thoughts?

Regards,

John



More information about the Squeak-dev mailing list