• anderson (49/49) Aug 14 2002 I'd like your opinion on the addition of this feature in D.
• Walter (7/7) Aug 14 2002 The idea of derivable enums is a good one, and was proposed a long time ...
• anderson (55/57) Aug 14 2002 ago.
• Robert W. Cunningham (8/15) Aug 16 2002 My main need for extendable enums would be for automatic collision-free

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

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

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

"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