Re^2: Why is a hash the default "object" in oo perl?

I use inside-out objects for my database persistence module, because it also helps with synchronization.

I'm intrigued. Can you show us some code?

One more thing:

So instead of using the pointer address as the key to the instance data hash, I use the primary key from the database. This is a big win, because there may be many objects instantiated that correspond to the same row in the database.

in contrast with:

So be sure to add:
sub DESTROY { delete $agedata{+shift}; }
[download]
.. and clear out all instance data hashes.

Surely that will pose a problem if you can have several objects pointing to the same hash item? What do you do about that, do you keep a reference count yourself?

And I've been pondering if weak references could be used, to do the cleanup automatically for you. I just don't see how...

Comment on Re^2: Why is a hash the default "object" in oo perl? Download Code

Replies are listed 'Best First'.
Re^3: Why is a hash the default "object" in oo perl? by nothingmuch (Priest) on Jul 18, 2004 at 12:56 UTC
I once had an LRU cache purge itself using DESTROY on linked list nodes, that knew how to delete themselves from a hash. The only way I found was to tell the nodes which lookup key they had. Retrospectively i would have the hash point to dually linked list nodes, which knew their keys too. Then each access would not create a new node, but rather bubble it up. That way the linked list doesn't grow. To purge either implementation, you just pop off the linked list, and let the ref count reach zero. -nuffin zz zZ Z Z #!perl	[reply]
Re^3: Why is a hash the default "object" in oo perl? by blokhead (Monsignor) on Jul 18, 2004 at 17:02 UTC
See Class::Tables for the full code. The basic idea is that the object implementation is a blessed scalar holding the tuple's primary key. I can also tell what database table it belongs to by what class it's blessed into. I use these two pieces of information to address a deep hash with all the accessor data. The general idea is: `my $DATA; sub id { ${+shift} } # $obj->column_name() # $obj->field("column_name") sub field { my ($self, $col) = @_; my $table = (ref $self)->_table; my $id = $self->id; return $DATA{$table}{$id}{$col}; }` [download] The DESTROY method I gave in the previous post was for the benefit of theAcolyte and the basic inside-out mechanism. You're right that in my code, since the data should stay around as long as there's an object that might need it, I have to do something a little more clever. I end up doing my own form of reference counting. Each time I make an object, I increment `$COUNT{$table}{$id}`. Each time an object is destroyed, I decrement that count and if the count became zero, clear out the appropriate part of the `%DATA` hash (and `%COUNT` as well). blokhead	[reply] [d/l] [select]


Just another Perl shrine
	PerlMonks