www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sets yet again :)

reply Fredrik Olsson <peylow treyst.se> writes:
Code says more than 1000 words:

enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };
// ...
class Stream {
   StreamFeature features();
   // ...
}
// ...
if ((someStream.features() && StreamFeatures.ISREADABLE) != 0)
   // ...

Pros: works now
Cons: What is more than 32 features, ugly even if != 0 is dropped.

enum StreamFeature { ISREADABLE, ISWRITEABLE, ISSEEKABLE };
set StreamFeatures { StreamFeature };
//..
class Stream {
   StreamFeatures features();
   // ...
}
// ...
if (StreamFeature.ISREADABLE in stream.features())
   // ...

Pros: No limit, looks good, is self commenting, focus is on
       functionality not implementation
Cons: Well... requires set support or at the very least a standard
       set lib.

// Fredrik Olsson
Mar 09 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Fredrik Olsson wrote:
 Code says more than 1000 words:
 
 enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };
 // ...
 class Stream {
   StreamFeature features();
   // ...
 }
 // ...
 if ((someStream.features() && StreamFeatures.ISREADABLE) != 0)
   // ...
 
 Pros: works now
 Cons: What is more than 32 features, ugly even if != 0 is dropped.
 
 enum StreamFeature { ISREADABLE, ISWRITEABLE, ISSEEKABLE };
 set StreamFeatures { StreamFeature };
 //..
 class Stream {
   StreamFeatures features();
   // ...
 }
 // ...
 if (StreamFeature.ISREADABLE in stream.features())
   // ...
 
 Pros: No limit, looks good, is self commenting, focus is on
       functionality not implementation
 Cons: Well... requires set support or at the very least a standard
       set lib.
 
 // Fredrik Olsson
Just write a set class. It's not /that/ hard.
Mar 09 2006
parent reply Fredrik Olsson <peylow treyst.se> writes:
Hasan Aljudy skrev:
 Fredrik Olsson wrote:
<snip>
 Just write a set class. It's not /that/ hard.
That I already have, two implementations: Set and SmallSet, the first using a hash table and the second a bit field for speed. But that is sort of not the point, if D did not have arrays I am quite sure no one would suggest "Write an array class", it is how Java and .net have solved it, but it is not the best solution, proved by both Same goes for strings "write a string class", the C++ crowd have settled for that, the D crowd have not, and I think we all feel better off that way. My argument is the same with sets, it is such a useful, beautiful and natural part of programming that it should not be treated as a second class citizen in some backwater library. // Fredrik
Mar 10 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Fredrik Olsson wrote:
 Hasan Aljudy skrev:
 
 Fredrik Olsson wrote:
<snip>
 Just write a set class. It's not /that/ hard.
That I already have, two implementations: Set and SmallSet, the first using a hash table and the second a bit field for speed. But that is sort of not the point, if D did not have arrays I am quite sure no one would suggest "Write an array class", it is how Java and .net have solved it, but it is not the best solution, proved by both Same goes for strings "write a string class", the C++ crowd have settled for that, the D crowd have not, and I think we all feel better off that way. My argument is the same with sets, it is such a useful, beautiful and natural part of programming that it should not be treated as a second class citizen in some backwater library. // Fredrik
I like the way Java implements String in a class. If D had a _standard_ array class, I think I'd use it. C++ std::string just sucks, the whole STL sucks, but that's another issue. You raise a valid point, but, for D, all we need is a standard Set class. It doesn't need to be built in. If you've writte a set class as you say, submit it to Walter, it might end up in phobos!
Mar 10 2006
parent Fredrik Olsson <peylow gmail.com> writes:
Hasan Aljudy skrev:
 Fredrik Olsson wrote:
 
 Hasan Aljudy skrev:

 Fredrik Olsson wrote:
<snip>
 You raise a valid point, but, for D, all we need is a standard Set 
 class. It doesn't need to be built in.
 
 If you've writte a set class as you say, submit it to Walter, it might 
 end up in phobos!
Perhaps you are right, but _I_ have found myself yearning for sets fifty times as often than I have felt the need for imaginary and complex reals. I will make them public shortly after gdc 0.18 is out, I think I can make it much neater with the template additions added after dmd 0.140. But then again, releasing it and making it part of Phobos might be a bad thing(tm), as if people would find it very usable there is a threat of a library implementation becoming the standard, when I still firmly think it is something that should be part of the language. For looks, optimization, and flexibility. // Fredrik
Mar 11 2006
prev sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
A very good point though! What if a "set" was nothing more than a enum whose 
values are shifted, rather than incremented. The type of the "set" would as 
big as needed for the set's values to fit:

set StreamFeature { ISREADABLE, ISWRITABLE, ISSEEKABLE };
// could be identical to:
enum StreamFeature { ISREADABLE = 1, ISWRITABLE = 2, ISSEEKABLE = 4 };

L. 
Mar 10 2006