Unless, of course, the following reasons apply:
- I want to future-proof myself against changing my requirements for membership.
- I want to future-proof myself against changing my requirements for operations performed on my set.
- I want to not worry about bugs in my code, but would rather use battle-tested code.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
- A set containing some strings and some objects doesn't make much sense and if you switch from a set of strings to a set of objects than the way the set is implemented will be the least of your worries. You'll have to change lots and lots of other things. Besides in such a case Tie::RefHash might very well be enough.
- You can't presume all future requirements. So any futureproofing is bound to fail.
- I doubt any module is as well tested as hash operations.
| [reply] |
- A set containing some strings and some objects that behave as strings makes perfect sense to me. For example, a set that contains some strings from user input and other strings that live in a DBM::Deep DB.
- No, I cannot presume all future requirements. But, I can presume that many future requirements will lead me to places that other peoples' future requirements led them. Therefore, with sets, I can guess that many future requirements will probably require one or more advanced set operations.
- Given that most sets are implemented as hashes, this is a non-starter. And, the issue isn't one of whether or not the hash operations are going to work. The issue is whether or not my implementation of the pieces of set theory I need will be as correct as that in a well-used module. A hash is not a set.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |