in reply to Re: CPAN indexes *.pm as "Documentation"? (Memory leaks)
in thread CPAN indexes *.pm as "Documentation"?

Hey, thanks!

I've been experimenting with something that might be what you're saying: the node class would have a number of arrays (e.g. @parent, @next_sister, @previous_sister, @first_daughter, @last_daughter). The objects are blessed references to scalars holding integers.

Getters and setters would dereference and assign the respective arrays based on the object's integer value: 
sub set_parent {
    my ( $self, $parent ) = ( $_[0], $_[1] );
    $parent[$$self] = $parent;
    return $self;
}

sub get_parent {
    my $self = $_[0];    
    return $parent[$$self];
}

[download]
When you construct the node, a new, unique integer is generated by the InsideOutFactory, and when the node's DESTROY is called, the integer value is returned back to the InsideOutFactory, to push it into a pool for reuse. The instance data consists of elements of the class arrays. Kinda like this: inside-out objects using arrays?

(Mind you, the memory leak problem so far hasn't been noticeable in day-to-day usage, but it does show up when I check with Devel::Cycle.)

Replies are listed 'Best First'.
Re^3: CPAN indexes *.pm as "Documentation"? (Memory leaks)
by BerntB (Deacon) on Oct 01, 2005 at 16:57 UTC
    Sounds like the biggest diff is that I use 'son' or 'sub' instead of 'daughter' -- shorter. :-)

    I have a method that gives a short unique ID-string. Easier to read (a number might be confused with other data). You probably get a little more speed of using arrays and ints.

    I only store sup and an array with subs in obj and use methods to find brothers. Fewer possible bugs to keep obj updated when deleting/adding/serializing/etc.

    I have Links between objects in different parts of the tree (you don't need that, I'd guess). Would have been better to make objects out of Links but I have a small subapi to e.g. add link, del link and find links to/from obj.

    In total, this was little code and never gave me any problem. If I should redo it I'd probably let the IDs be invisible in the api, just to be cleaner.

[reply]
      I have a method that gives a short unique ID-string. Easier to read (a number might be confused with other data). You probably get a little more speed of using arrays and ints.
      I believe this is the "classic" InsideOut approach, right?

      Update: I read back in the thread and on your scratchpad. I see what you're doing now :)

      I agree that that is probably slightly less bug prone, though you wouldn't really notice except for the few methods that actually dig into the underlying data directly (as an aside: me sticking to my own API rather than breaking encapsulation has been a godsend while refactoring).

      The main reason I am thinking about the array-index-as-object approach is that this might be the approach people I work with will adopt also as a serialization format to transmit trees (between python, Java, C++, through CORBA, to databases, to XML.... Aaaarg...), so it seems natural to extend that to the underlying data structure. I wonder how sparse and random the arrays become after a few cycles of reclaiming by the InsideOutFactory?
      I only store sup and an array with subs in obj and use methods to find brothers. Fewer possible bugs to keep obj updated when deleting/adding/serializing/etc.
      I notice that I'm doing a lot of calls for sisters/children/parents, and not that many tree modifications - so calculating the relationships for each call seems inefficient.
      I have Links between objects in different parts of the tree (you don't need that, I'd guess). Would have been better to make objects out of Links but I have a small subapi to e.g. add link, del link and find links to/from obj.
      I'm a bit unclear what you mean by links. Currently, I have a $self->{'GENERIC'} = {} field in each node object (with getters and setters), so I can attach additional generic key/value pairs to the objects.

      Anyway, interesting stuff to ruminate on. Do you have your code on CPAN or something?
[reply]
[d/l]
        The main reason I am thinking about the array-index-as-object approach is that this might be the approach people I work with will adopt also as a serialization format to transmit trees
        Ah... good reason. I have a presentation API on top of my work code that would be easy to stub and use RPC calls to other languages.
        I'm a bit unclear what you mean by links.
        References to objects outside of the direct inheritance hierarchy. (Nothing you need, I'd guess.) I don't want code to store the IDs in strings or something because they might be renumbered. If e.g. a part of an object definition are to be copied into some other place.
        Do you have your code on CPAN or something?
        The code is mostly done. I am writing a simple CGI user interface, will do some example and trying to force myself to write documentation. :-)

        Give it a couple of weeks (I've said that for a month :-( ).

[reply]

In Section Seekers of Perl Wisdom