in reply to RE: Module Proposal: Tie::SortHash
in thread Module Proposal: Tie::SortHash

I had origionaly thought of doing that, however, they both have different symantics, and are fairly particular:

Tie::IxHash attempts to give you more of an array like behavior and keeps the order that things were added to the hash, just like arrays. I'm not trying to do that.

Tie::LLHash gives you the ability to poke and prod the hash, while keeping it's state of where and how things were entered into it. I'm also not looking to do that.

The advantage is that there is no overhead or fluf with Tie::SortHash. It's designed to do one thing, rather transparently. I like the transparent part, you don't get that with the other two modules.

Transparent meaning, for most cases, there's only two 'out of the ordinary' lines in your program. One usees Tie::SortHash, the other implements the tie.

--
Casey

Replies are listed 'Best First'.
RE: RE: RE: Module Proposal: Tie::SortHash
by KM (Priest) on Aug 18, 2000 at 23:58 UTC
    If your internals can't work with theirs (I would doubt that they can't work together), then it would be ok as it's own module. It just seems that this would fit nicely, at least into IxHash. It keeps the order of the entered keys, but also has some ordering/sorting methods (Reorder, SortByKey and SortByValue). With add something like SortByInput (off the top of my head) it seems you would only need to reorder the array IxHash keeps in parallel to the hash.
    Just my $.02, but I do like the idea. I would only want to make sure it wouldn't be more valuable in conjunction with another module, rather than stand alone. I suggest asking for any comments on the modules list.

    Cheers,
    KM