www.digitalmars.com         C & C++   DMDScript  

D - Feature request

reply "anderson" <anderson firestar.com.au> writes:
I'd like your opinion on the addition of this feature in D.

Extendable enumerators.

class G
{
public:
    enum A
    {
        X, //1
        Y  //2
    };

    run(A value);
}

class Z : G
{
   public:
    enum B : A
    {
        Z //3
    };

    run(A value); //Virtual and should also except enum B
}

At least I would find this feature useful because I could specify enum A and
subsuquent users could extend this concept further, overloading any function
that use it in increase it's useablilty. Enum A could be changed and enum B
would be updated to cate for this. I suppose polymorphism with classes could
be used for this, but I think my idea has some merit.

Syntax sugar

Also I'd like to request an flag enum, as sometimes it's good to have each
bit named. However, I suppose you could used a bit array with the enum as an
index instead in may cases.

class G
{
public:
    enum (flag) A //People in this group really love their brackets
    {
        X, //1
        Y  //2
    };

    run(A value);
}

class Z : G
{
   public:
    enum (flag) B : A
    {
        Z //4
    };

    run(A value);
}
Aug 14 2002
parent reply "Walter" <walter digitalmars.com> writes:
The idea of derivable enums is a good one, and was proposed a long time ago.
The problem is I've never seen a need for it in actual use.

The idea of automatically assigning bit values to enums is also a good one,
and a good friend of mine keeps asking me for it <g>. I hesitate to
implement it, though, because the application would likely be better served
by doing better support for bit arrays stuffed in integers, and then
indexing them by bit number.
Aug 14 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ajduk9$1pei$1 digitaldaemon.com...
 The idea of derivable enums is a good one, and was proposed a long time
ago.
 The problem is I've never seen a need for it in actual use.
I was thinking of using it for an action type of command. something like... class unit { enum ACTION { USE, } int action(ACTION A); } class player { enum PLAYERACTION : ACTION { ATTACK, } int action(ACTION A); } Of course action could be divided into several methods, but then it can't be used polymorphicly (as easily). It simply provides another means of doing something. This next example is probably better. class unit { enum (enable) ENABLEBIT { VISIBLE, DIE, } void enable(ENABLEBIT); //These only need to be written once void disable(ENABLEBIT); //and probably would exist higher up the tree (class enablestuff) bool isEnabled(ENABLEBIT); } class player : unit { enum (enable) : PLAYERENABLEBIT : ENABLEBIT { MOVEMENT, } } class item : unit { enum (enable) ITEMENABLEBIT : ENABLEBIT { PICKUPABLE, } } if (someunit.isEnabled(unit.VISIBLE | DIE)) ... someplayer.isEnabled(unit.VISIBLE); someplayer.isEnabled(unit.MOVEMENT); someunit.enabled(unit.PICKUPABLE); ect... Quite useful for state machines.
Aug 14 2002
prev sibling parent "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Walter wrote:

 The idea of derivable enums is a good one, and was proposed a long time ago.
 The problem is I've never seen a need for it in actual use.

 The idea of automatically assigning bit values to enums is also a good one,
 and a good friend of mine keeps asking me for it <g>. I hesitate to
 implement it, though, because the application would likely be better served
 by doing better support for bit arrays stuffed in integers, and then
 indexing them by bit number.
My main need for extendable enums would be for automatic collision-free extending of library error code sets. I've wrapped a thin layer around many a library, and would like to be able to extend the error codes in a way that would still let my wrapper work with new versions of the library that may define new error codes. Symbols are good. Literals aren't. -BobC
Aug 16 2002