If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer?
A set of characters, one would think. But do you care what class is used to implement that set of characters? -- One argument says that it should be a Set, because that’s what asSet answers when it is sent to other collections. It’s conceivable that you might initially populate the set with Characters, but then add other kinds of object. -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d -- A third argument says that you shouldn’t care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. This test is already overridden once, in IdentityBagTest, because the result of sending asSet to an IdentityBag is not a Set — it’s an IdentitySet. So, indeed, there is already a precedent for asSet returning a set object that is not an instance of Set. I think that the test is bad, and should be changed. But this raises the larger question: if you want to know whether or not a collection has set-like behaviour, what is the right way of finding out? (aCollection isKindOf: Set) reads OK, but is actually wrong, because it’s testing the implementation, and not the behaviour. A predicate on all collections (isSet would be the obvious name) would seem to be indicated. And that’s what the test should be using. (You might ask why CharacterSet and WideCharacterSet are not subclasses of Set. This answer is that subclassing Set implies inheriting a hash table, and the raison d’être for CharacterSet is that it does not use a hash table.)
