- 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] |