in reply to Re: Re: Are array based objects fixed length?
in thread Are array based objects fixed length?

Yes, and of course I do. I respect other people enough that I want to provide a tool that just works, for a sufficiently large number of client classes.

If you only care about "a sufficiently large number of client classes" anyway, maybe you should quit with what you have. Most classes are probably implemented as refs to hashes that don't include your 'safely named key', don't rely on the number of key/value pairs they contain, don't iterate through their own keys, don't use closures to privatize data, etc. Pretty much everything from there on out is a special case.

I noticed you mentioned Smalltalk in a reply to Abigail-II. The tools you described are development tools. They are designed to help a developer look into instance internals. That's a necessity. There is obviously a significant difference between looking at internals during development and changing them during runtime.

Good luck (and may the OO gods have mercy on you!)

-sauoq
"My two cents aren't worth a dime.";
  • Comment on Re: Re: Re: Are array based objects fixed length?

Replies are listed 'Best First'.
Re: Re: Re: Re: Are array based objects fixed length?
by pdcawley (Hermit) on Aug 01, 2002 at 13:24 UTC
    Ah... the problem is that the client classes we can currently deal with don't include some classes that I want to deal with. And we haven't yet come up with a 'hook API' to allow more complicated classes to be persisted, so we can't stop yet.

    As for the distinction between development tools and 'everything else', well, in a very meaningful sense Pixie is a development tool in that it will allow the average developer to make her objects persistent with almost no work. If that's not development support I don't know what it is. And check out the implementation of tools like SmartRefStream in your local Smalltalk image; there's an object persistence system that indulges in some serious voodoo.