Why does #like: have to be disabled? Why can't you provide an implementation for it? Every add: has an additional nil check. I'd bet that in 99.9999% of the cases, the nil check is effectively overhead. In efficient implementations of hashed collections, you can tell when you add a few message sends because it costs about 10% (as I measured for findElementOrNil: in VW's IdentitySet). Besides the additional complexity, is do: actually correct? How can a set includeNil but have a tally of 0? I am suspicious that add: should increase the tally when you add nil (more complexity). Every removal has an additional nil check. I also note that the tally is not updated either... So. I wanted to point out that these 8 refined methods give you: * Inflexible implementation. If Set changes, then you have to change GenericSet too. * Additional code complexity that people have to deal with. * But you can add nil to a Set. Let's say you write code with GenericSet and use the fact that you can add nils. In the vast majority of Smalltalks (all?), you can't add nil to a set. So, if you want to port code, you have to port GenericSet (and apply the necessary refinements N times). You can't use the everyday Set that IIRC is specified in the ANSI standard. Again, is it worth the effort? Finally, of course you compare GenericSet to e.g.: HPS, and there's no complexity at all. Nevertheless, I've come to think that "I can do it" generally doesn't mean "I should do it". Andres. Igor Stasenko wrote:
Here the implementation of Set which can include nils. Where do you see so-called 'complexity'? I had to override only 8 methods.
2009/7/3 Igor Stasenko <siguctua@gmail.com>:
2009/7/3 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:
Unlike arrayed collections, hashed collections use a sentinel value for implementation purposes. Such collections shouldn't be allowed to contain the sentinel because doing so introduces unnecessary complexity for the vast majority of practical applications. It's not worth it. If adding nil to a set is important, then using self as the sentinel could do (at the cost of initializing the set to contain self at all slots when the instance is created, thus duplicating the nilling the VM does for you). But then, the set shouldn't contain itself.
I think you are mixing an object's interface with its inner implementation details. A Set can include any object in itself, without any discrimination. But its implemented in such way that it's impossible to include nil in it. So, its not worth proving that due to limitation, which comes from implementation detail, its not worth to have Sets which can include nils.
-- Best regards, Igor Stasenko AKA sig.