Re^3: CPAN indexes *.pm as "Documentation"? (Memory leaks)

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.

Comment on Re^3: CPAN indexes *.pm as "Documentation"? (Memory leaks)

Replies are listed 'Best First'.
Re^4: CPAN indexes *.pm as "Documentation"? (Memory leaks) by rvosa (Curate) on Oct 01, 2005 at 21:23 UTC
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]
Re^5: CPAN indexes *.pm as "Documentation"? (Memory leaks) by BerntB (Deacon) on Oct 02, 2005 at 13:41 UTC
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]
Re^6: CPAN indexes *.pm as "Documentation"? (Memory leaks) by rvosa (Curate) on Oct 03, 2005 at 08:00 UTC
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. "Has-a" versus "Is-a" relationships? That's what's bugging me: nodes on trees (especially terminal nodes) ought to be crossreferenced with Operational Taxonomic Units (more sane people would call them "species"...), which in turn ought to be crossreferenced with comparative data (e.g. DNA sequences). None of these relationships are through inheritance, but more data-oriented rather than object-oriented. This all works in that I have methods to match up the different types of information by species name, and build references between the objects - but now everything is one network of circular references that I'm pretty sure keeps floating somewhere in RAM space after it's gone out of scope (sidenote: how might you test that???). I'm interested to see how you go about doing that, so will you post a message to announce your module?	[reply]