• Fredrik Olsson <peylow treyst.se> Mar 09 2006
• Hasan Aljudy <hasan.aljudy gmail.com> Mar 09 2006
• Fredrik Olsson <peylow treyst.se> Mar 10 2006
• Hasan Aljudy <hasan.aljudy gmail.com> Mar 10 2006
• Fredrik Olsson <peylow gmail.com> Mar 11 2006
• "Lionello Lunesu" <lio remove.lunesu.com> Mar 10 2006

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:


 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 
Java, C# and others "knows" about arrays anyway.
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 
 Java, C# and others "knows" about arrays anyway.
 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:






 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.