Maybe one of those modern ORM's that create the tables from your
classes rather than the other way around would be better for shoes.
It's unlikely shoes will be in a situation where it has to bend to the
existing design of an SQL server. I don't remember the name of any of
those new age ORM's though. Could be nifty to just write a class and
have data magically be stored permanently... like a persistent object.
Woah, now hold on a second, is that a far better idea?
Could we 'include Persistence' in to (maybe singleton) classes in
shoes, and have them define a starting state in the initialize method
and then when the app closes, be serialized in to some place, and when
launched, recreated (via allocate, not new, avoiding initialize) and
be exactly how they were left? Yay or Neigh?
It would create a funky illusion that the class had never actually
disappeared, and that it was still the exact same class as the last
time you ran the app. Well, except for that pesky object_id, and the
way it would explode if you tried to store an unserializable object in
it. :)
