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?
Snippets of code should be wrapped in
<code> tags not<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).