My guess is that you should probably do

$obj->[0]=Pixie::Object::Info->new()
[download]

But I still say that without knowing the operations you need to perform on your objects (why pick arrays?) there is no way to give a really good answer.

update
I think you probably should just use a different route. _Demand_ that any client class must support a given method, lets say $obj->for_pixie(). This method MUST provide the functionality that when called with a value it stores it. When called at all it returns its current value. Something like

sub for_pixie {
  my $self=shift;
  $self->[0]=shift if @_;
  return $self->[0];
}
[download]

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Um. No. An important design goal of Pixie was that you should be able to throw any object (for only slightly limited values of 'any') you like at pixie and the pixie would do its magic and store it. We already handle hash based objects quite handily, and array based objects that implement an _oid can be dealt with as 'top level' objects. If they don't implement _oid they can only be used in the contents of objects, subject to certain limitations.

In general, the objects that are stored should never need to know that they've been persisted (they may want to know, but that shouldn't be a requirement). For instance, I have objects stored in Pixie, working quite happily, that have timestamps implemented using Time::Piece. Getting that to work too precisely no extra work on my part (apart from the work of implementing Pixie in the first place of course). Of course, there are CPAN modules that will need work to handle -- Set::Object, for instance, is a very handy class which can't be directly persisted by Pixie (which uses Data::Dumper to do a lot of its heavy lifting). However, we have a way forward, using $Data::Dumper::Freezer and Data::Dumper::Toaster, which should make even 'pathological' objects tractable to being stored (though maybe not to being 'top level' objects), and which we can use to provide hooks to users who need them.

Hmm... maybe I should prepare a proper medition. Until then, you can take a look at the current (horribly undocumented) state of the Pixie art on CPAN.

You are doomed, man, you are doomed. But that's your own fault, because you break a cardinal rule of OO programming: encapsulation. Don't poke around in someone elses implementation.

If you think array based objects are a problem, how do you want to deal with scalar based objects? Or filehandle based objects, like some (all?) of the IO:: classes?

Of course, you are not free of problems with hash based objects either. Such an object might have already a "__Pixie" attribute. Or it has an overloaded stringify that's going to do something with all the key/value pairs. Not to mention all the existing techniques out there that prevent accessing/setting keys that aren't in a predefined set.

Abigail

Oh, I know. The idea is to come up with a sufficiently useful set of assumptions about the stored objects that will offer a useful set of behaviours. And those assumptions will be documented so users will be aware of the issues. The next step after that is to provide hooks so objects can, if necessary be complicit with Pixie.

Encapsulation is overrated anyway. Hell, even Smalltalk, the granddaddy of OO systems, provides tools (inspectors, browsers...) to get round encapsulation.

The code will probably not be a pretty, but that way you might be able to add 'invisible' data (or objects) to another object.

Hope this helps.

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]

The problem with that approach is that it'd be horribly, horribly slow. The anonymous classes that clean up after themselves trick is a pain to program, but it's a one time cost paid only when the object is first fetched. The tied object cost is paid every time someone accesses the array.

The problem with that approach is that it'd be horribly, horribly slow.

Yes it will be :-)

Maybe you could insert a DESTROY method into the targeted object, possibly aliasing any existing ones, and do the cleanup there?

Something like:

if (ClassName->can('DESTROY') {
   *ClassName::OLD_DESTROY = \&ClassName::DESTROY;
   *ClassName::DESTROY = sub { 
       cleanup_object($_[0]);
       goto &$_[0]->DESTROY;
   }
}
else {
   *ClassName::DESTROY = \&cleanup_object($_[0]);
}
[download]

Update: this will not get you the object id... hmmm...

Joost frowns, going to get another cup of coffee

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]

I agree with those other posters who believe that your suggested approach is doomed, because it makes too many assumptions about the way that objects - especially array-based objects - might be used. I suggest taking a different tack, outlined below.

Keep a hash in the Pixie package, let's call it %objects, which uses the object ID number as a key and has a weak reference to the allocated object as its value. Whenever anybody calls get, the first thing you do is to iterate through your hash looking for undef values; if you find one, unlock the object in the database.

One disadvantage of this approach is that objects won't be released immediately they go out of scope. Instead it will happen the next time somebody calls get. I'm not sure how much of a problem that is for you. Another potential problem is that scanning the hash might become slow if large numbers of objects have been allocated. Obviously you can trade these two problems off against each other: at one extreme, if timely release is not required, you could not bother to release objects at all until exit time. The hash would then just be used to check that no instance of the object is already in existence. Somewhere in between the two extremes, you could do a "garbage collection" run whenever the number of allocated objects exceeds a certain number.

(In a multithreaded setting, one can also imagine a JVM-like approach where a background thread periodically checks for expired objects.)

I hope I haven't misunderstood the problem.

.robin.

Nice idea. I think I want more immediacy though, otherwise there could be problems with multiple processes where one process takes forever to release the lock, and a pile of other processes hang on that. However, a combined approach using blessing into custom classes might work (modulo the problem with spooky inaction at a distance, where one has to worry about both the representation of an object (hash, array, whatever) and whether it has overloading or not.)

Time to lobby Hugo about some things for perl 5.9...

Or something like that. It's a pretty hard problem. *shrugs*

<thought type="evil">Could you set up an overloaded @{} in UNIVERSAL that would implement this behavior? That would solve the problem of Pixie::Array's blessing. Alternatively, Pixie::Arrays could keep track of their "real" blessing and redispatch:

package Pixie::Array;

sub PIXIE_getoid { return shift->{oid} }
# ...
sub AUTOLOAD     { return shift->{realobj}->$AUTOLOAD(@_) }
[download]

=cut
--Brent Dax
There is no sig.

The problem with overloading @{} in UNIVERSAL is what happens when one of the storedclasses has overloading in place?

I have already discovered to my cost that reblessing and overloading do not play well together; you get all sorts of painful spooky inaction at a distance (ie: The spooky action at a distance you were hoping would happen doesn't).

However, my boss recently played a blinder when he had the idea of using XS to hang sv_magic off the object which, (after a certain amount of buggering about due to problems with sv_unmagic being a little, well, eager) combined with a weakref back to the object for DESTROY convenience gives us what we need. And, marvellously, it dramatically simplifies our object tracking and caching code and removes the need to rebless into a 'managed' class. Now the only reblessing we need to worry about is when a proxy object gets restored.

This is probably not the place for a Pixie walkthrough though. I'll see about preparing a meditation on some of the tricks we get up to in order to 'just work' for the client.

my $p_hash=[{key=>index,key1=>index1},'value key', 'value key1'];
[download]

$p_hash->[index];
or
$p_hash->{key}
[download]

I think you may have missed my point. Pixie is trying to work with whatever object representation is thrown at it, we've already made the choice of which representation(s) to use within Pixie itself.

 my $glob = eval "*" . ref($obj) . "\::DESTROY";
 my $save = *$glob{CODE};
 my $newsub = sub { warn("NEW DESTROY CALLED\n"); goto &$save };
 no strict;
 *{ref($obj) . "\::DESTROY"} = $newsub;
 use strict;
[download]

I smell Attributes in your future. You should be able to set an attribute on the object being persisted that is a Pixie::Object, if I understand attributes correctly (which I may not). (To be a little more purticular, I think you want an attribute on the array, not the (blessed) ref to it.)

Unless you can get your class to read the documentation of those modules it is futzing with and modify its own behaviour based on what it learns, I suggest you reconsider your design.

Maybe I'm missing something but I don't understand why you aren't just creating containers for the objects that you store rather than modifying the objects themselves. Isn't that how generalized persistence is usually implemented?

Tacking locking onto that is relatively easy. I used FreezeThaw and BerkeleyDB to do exactly this for in-house use. I've since upgraded it to use Storable.

Good luck.

-sauoq
"My two cents aren't worth a dime.";

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.

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.";