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

Are you really mussing around in the internals of instances of other peoples' classes? Have you no respect?! :-)
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.

To do this, I have to futz with object internals. It's easy enough with hashes; one can just add a 'safely named' key to the hash and document what you've done, and the vast majority of code will continue to work happily. And if it doesn't, you provide hooks to allow the user to adapt his code so that it will work transparently. (Easy things easy, hard things possible).

It's less easy with other object representations (that haven't taken advantage of the provided hooks that is). The aim is to make it as easy as possible. I can see ways forward, but I'll have to jump through more hoops to reach my destination. Though thinking about it, I'll probably have to jump through those hoops anyway if I want to support, say, regex based objects...

Why am I doing this? Well, all the right reasons. Laziness, Impatience and Hubris. I don't like repeating myself, either in building schemas, reimplementing yet another simple minded container, or solving the 'Fetching the World' problem for the nth time. I'm not going to spend my time waiting for someone else to solve my problem. And I'm confident that approach to this that James and I have cooked up is better than all the other approaches out there.

Pixie is about reducing the hoopage that a Pixie user has to deal with to make her objects persistent. If that means that we (Pixie's implementors) have to deal with way more hoopage, that's okay; if (when) we do it right, it'll mean that nobody else has to jump through those particular hoops again.

  • Comment on Re: Re: Are array based objects fixed length?

Replies are listed 'Best First'.
Re: Re: Re: Are array based objects fixed length?
by sauoq (Abbot) on Jul 29, 2002 at 16:22 UTC
    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.";
[reply]
      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.

[reply]

In Section Seekers of Perl Wisdom