• Fredrik Olsson (27/27) Mar 09 2006 Code says more than 1000 words:
• Hasan Aljudy (2/34) Mar 09 2006 Just write a set class. It's not /that/ hard.
• Fredrik Olsson (14/16) Mar 10 2006 That I already have, two implementations: Set and SmallSet, the first
• Hasan Aljudy (8/33) Mar 10 2006 I like the way Java implements String in a class.
• Fredrik Olsson (12/23) Mar 11 2006 Perhaps you are right, but _I_ have found myself yearning for sets fifty...
• Lionello Lunesu (7/7) Mar 10 2006 A very good point though! What if a "set" was nothing more than a enum w...

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

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.

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

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!

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

"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.