"Michael C. Davis" wrote: > Hi list, > > Can anyone recommend a CPAN or Perl core module that implements a container > class / collection / managed list or somethign like that. I've found a > couple that I'm about to study now: > > Tie::Collection > Class::Composite > Class::Container > > Is there such a module that anyone has found especially useful or suitable?
Not directly. Hint--you may not need them. Mosdt of the functionality you indicate below is already built into either the hash or array structure in Perl.These can hold references to any kind of object, including other hashes or arrays. By storing references, you can effectively nest containers to arbirary depths.. > > Basically my program has several data structures that, over time, are > beginning to want similar functions. Gathering all the desired functions > and thinking ahead a little (just to try something different) yields the > following list: > > new / destroy # mostly not needed with hashes/arrays > add, delete, change #available in a variety of forms > exists # ditto: grep, first > get # not needed unless you are doing OO > keys # available in hash > num/length # got it Since you seem to be just starting in building functions in Perl, I might suggest a stylistic change. Perl Generally uses choo_choo style rather than camelBack. Most of us find it more readable. CamelBack should generally be reserved for class and package names. Variable names for objects are genrally lowercase, as with any other variables. > > asList # mmm, not sure. What does asLast do? > makeKey # Probably not needed > merge # depends on what you mean by merge > predecessor, successor > rename / rekey # bad logic. Don't try this--in any language > sequentialFirst / sequentialLast > sequentialNext / sequentialPrev > orderBy / sortBy / sortRoutine > reindexMode: all-at-once vs as-needed > keyingMode: unique (could be implemented as hash) vs set (duplicate keys > allowed) > fromFile > toFile > tieFile > > I have in mind that all this occurs in memory (speed is important, with > portions of my code nested 8 loops deep and executing a couple million > times). Still, my function list looks an awful lot like database > functionality, and a good solution may be an 'in-memory' form of DBM/DBI Maybe. It is really not a good idea to make implementation decisions like that until you have modeled the process. Can you describe your system in real--world terms. I have a feeling that you may be getting more complicated than your problem requires when using Perl's standard built-in sequential [array] and labelled [hash] containers. > > (which is on my list to look at) or something like that. Regardless, a > good class design would hide the 'in-memory/as-file' implementation detail > behind the class's interface, so that all that is transparent to a user of > the class. You say class, as in singular. Yet above, you speak of having numerous data structures. This situation would suggest to me that you need numerous classes. If you are finding the need to structure your data differently, it usually means that you are looking at a different concept, which can be most cleanly described in a class of ts own. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
