New set class

[Stephan Diehl]

Michiel wrote:
> Stephan Diehl wrote:
> 
>>> I have written a new class to represent sets, with several useful
>>> features. Uploaded for your review and free use. I don't know much about
>>> open source and licensing, but I request that if you use the class, that
>>> you keep my name in the author section of the documentation.
>>>
>>> http://files.michiel.eu/set.d
>>>
>>> Tell me what you think.
>>>
>> excelent. I somewhat missed some subset operations. If it were up to me,
>> I'd use the opCmp operator for this (just like they do in python).
> 
> You're right! I missed the subset operations. :)
> 
> Unfortunately the opCmp operator is taken. Implementing that correctly
> allows a set to be a key-type for an associative array (or the type of
> another set).
> 
> I can't make it double as a subset operation, because sets would have to
> be declared equal if one is not subset of the other. Even if they are
> not, indeed, equal. This would break their proper definition.
> 
> For a moment I was tempted to use the shifting operators, because
> they're only one character apart. But I don't think I like it. They
> already have a non-shifter use (right, Walter? :)). A third would be
> confusing. Besides, <<= (which would mean: non-strict subset) is
> recognized as an op= (or: opAssign) operator.
> 
> I also considered the 'in' operator for non-strict subset, but it's
> already used as a membership operator, and overloading it for this would
> also be confusing.
> 
> I will just create a function for it.
> 

the python people have 'set' and 'frozenset' 
(http://docs.python.org/lib/types-set.html). The main difference between 
these two is basicly, that a 'set' can't be the key to a dict (and 
therefore not being a member of a set. To make it short: every member of 
a set must be immutable, or, to be more technical, must always produce 
the same hash value. This really makes sense, if one thinks about it a 
bit (and one wants to model sets in the more mathematical sense)