www.digitalmars.com         C & C++   DMDScript  

D - named enums

reply "Dario" <supdar yahoo.com> writes:
In C we are able to write:
    enum A { a1, a2, a3 };
    int main()
    {
        enum A a;
        a = a1;
        a = a2;
        a = a3;
        return 0;
    }
Why is this prevented in D?
Doesn't anybody think it is useful? I do.

Consider Pavel's streams.
You would write "new File('file.txt', Out);"
instead of "new File('file.txt', FileMode.Out);"!
Jun 13 2003
next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
Dario wrote:
 
 In C we are able to write:
     enum A { a1, a2, a3 };
     int main()
     {
         enum A a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }
 Why is this prevented in D?
 Doesn't anybody think it is useful? I do.

I think currently you have to use the long form or define an alias: enum A { a1, a2, a3 }; alias A.a1 a1; int main() { A a; a = a1; a = A.a2; a = A.a3; return 0; } -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Jun 13 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Dario" <supdar yahoo.com> wrote in message
news:bcd06e$1af0$1 digitaldaemon.com...
 In C we are able to write:
     enum A { a1, a2, a3 };
     int main()
     {
         enum A a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }
 Why is this prevented in D?
 Doesn't anybody think it is useful? I do.

Useful? Yes, in small programs, or those that do not use any shared/common libraries. Practicable? Not in the slightest. Less typing now almost always means more typing later.
 Consider Pavel's streams.
 You would write "new File('file.txt', Out);"
 instead of "new File('file.txt', FileMode.Out);"!

Jun 13 2003
parent "Dario" <supdar yahoo.com> writes:
 Useful? Yes, in small programs, or those that do not use any shared/common
 libraries.

 Practicable? Not in the slightest. Less typing now almost always means

 typing later.

Thid doesn't seem to be the case. You ALWAYS type less. Why should this cause you type more? For example, File.this(HANDLE, FileMode) is passed a FileMode value. So the compiler knows where to look for identifiers like In and Out which I pass to the constructor. The problem is probably this: void func(char[] filename) { FileMode Out = In; File f = new File(filename, Out); // what is passed? local Out or FileMode.Out } I think the compiler should consider this an ambiguity error. (You can change the variable name so that it doesn't make any conflict.)
Jun 14 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:bcd06e$1af0$1 digitaldaemon.com...
 In C we are able to write:
     enum A { a1, a2, a3 };
     int main()
     {
         enum A a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }
 Why is this prevented in D?
 Doesn't anybody think it is useful? I do.

There are two types of enums in D, named and unnamed. Named: enum A { a1, a2, a3 }; int main() { A a; a = A.a1; a = A.a2; a = A.a3; return 0; } Unnamed: enum { a1, a2, a3 }; int main() { int a; a = a1; a = a2; a = a3; return 0; }
 Consider Pavel's streams.
 You would write "new File('file.txt', Out);"
 instead of "new File('file.txt', FileMode.Out);"!

Common practice in C is to: enum FOO { FOObar, FOOdef }; to avoid name collisions. The aim in D is for the more sensible FOO.bar and FOO.def. You can still emulate the C version if you really want to: enum { a1, a2, a3 }; alias int A; int main() { A a; a = a1; a = a2; a = a3; return 0; }
Jun 15 2003
prev sibling parent Burton Radons <loth users.sourceforge.net> writes:
Dario wrote:

 In C we are able to write:
     enum A { a1, a2, a3 };
     int main()
     {
         enum A a;
         a = a1;
         a = a2;
         a = a3;
         return 0;
     }
 Why is this prevented in D?
 Doesn't anybody think it is useful? I do.

What you're asking for is ambiguous. If you mean that a1 should exist in the parent namespace, then you can do that this way: typedef uint A; enum : A { a1, a2, a3 } If you mean that the enumeration should be identified based on context, it's possible, but I'm agnostic. I didn't like named enumerations when I started either, now I use them. This looks good for small functions, but I get enough trouble with large functions where I can't remember what "true" means in this argument's context.
 Consider Pavel's streams.
 You would write "new File('file.txt', Out);"
 instead of "new File('file.txt', FileMode.Out);"!

I don't like handing firmament-altering parameters to functions anyway; "new CreateFile('file.txt')" would be nicer to me, "ReadWriteFile" for the third variation. Or just the ol' "rw" method. I like that.
Jun 15 2003