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);
}

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.

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

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