View mode: basic / threaded / horizontal-split · Log in · Help
August 10, 2004
Enums can be annoyingly verbose...
I have mentioned this before, but I kinda want some more opinions on the 
matter/idea.

Currently we have to specify an enum by it's full name, this can be quite 
long and you can end up writing/copying/pasting the enum name a few times.

Surely it's possible in most cases for the compiler to determine the Enum 
name and thus it's not really required.

Example:

enum FooBarBaz : ushort
{
  THE   = 0x0001,
  QUICK = 0x0002,
  BROWN = 0x0004,
  FOX   = 0x0008,
  JUMPS = 0x0010,
  OVER  = 0x0020,
  THE   = 0x0040,
  LAZY  = 0x0080,
  DOG   = 0x0100
}

void fooBar(FooBarBaz a) {}

void main()
{
  //current method
  fooBar(FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.LAZY|FooBarBaz.DOG);

  //proposed method
  fooBar(THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG);

  //alternate method
  fooBar(with(FooBarBaz){THE|QUICK|BROWN|FOX|JUMP|OVER|THE|LAZY|DOG});
}

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
August 10, 2004
Re: Enums can be annoyingly verbose...
"Regan Heath" <regan@netwin.co.nz> escribió en el mensaje
news:opschrxff75a2sq9@digitalmars.com
| enum FooBarBaz : ushort
| {
|    THE   = 0x0001,
|    QUICK = 0x0002,
|    BROWN = 0x0004,
|    FOX   = 0x0008,
|    JUMPS = 0x0010,
|    OVER  = 0x0020,
|    THE   = 0x0040,
|    LAZY  = 0x0080,
|    DOG   = 0x0100
| }
|

You can do it like this:

typedef ushort FooBarBaz;
enum : FooBarBaz
{ ... }

-----------------------
Carlos Santander Bernal
August 10, 2004
Re: Enums can be annoyingly verbose...
or you can do it like this.

enum : ushort
{
  THE=0x01;
  ...
}

only problem is that you lose the enum name, which is nice to have if you
have conflicting names (but that shouldn't happen very often).
August 10, 2004
Re: Enums can be annoyingly verbose...
On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley <kb3ctd2@yahoo.com> 
wrote:

> or you can do it like this.
>
> enum : ushort
> {
>    THE=0x01;
>    ...
> }
>
> only problem is that you lose the enum name, which is nice to have if you
> have conflicting names (but that shouldn't happen very often).

Thanks, I didn't realise you could have un-named enums.

However I still think there is merit in my idea, Walter how hard would it 
be to have the compiler treat this:

  fooBar(THE);

the same as

  fooBar(EnumName.THE);

given that

  void fooBar(EnumName a);

basically tells you what to expect.

?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
August 10, 2004
Re: Enums can be annoyingly verbose...
Regan Heath wrote:
> On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
> <kb3ctd2@yahoo.com> wrote:
> 
>> or you can do it like this.
>>
>> enum : ushort
>> {
>>    THE=0x01;
>>    ...
>> }
>>
>> only problem is that you lose the enum name, which is nice to have if you
>> have conflicting names (but that shouldn't happen very often).
> 
> 
> Thanks, I didn't realise you could have un-named enums.
> 
> However I still think there is merit in my idea, Walter how hard would 
> it be to have the compiler treat this:
> 
>   fooBar(THE);
> 
> the same as
> 
>   fooBar(EnumName.THE);
> 
> given that
> 
>   void fooBar(EnumName a);
> 
> basically tells you what to expect.
> 
> ?
> 
> Regan
> 

The reason that it requires a fully qualified name is to prevent name 
clashes, and to make the code more clear.  What would the compiler do if 
you had:

void fooBar(ushort s);

enum Foo : ushort { one, is, the, first, number }
enum Bar : ushort { just, one, more, time }

fooBar(one); // would it be Foo.one or Bar.one?

Requiring Foo.one or Bar.one provides clearer code.  If you just want 
global constants, then use an anonymous enum, that's what it's there for.

-Deja
August 10, 2004
Re: Enums can be annoyingly verbose...
On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine <deja@scratch-ware.net> 
wrote:
> Regan Heath wrote:
>> On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
>> <kb3ctd2@yahoo.com> wrote:
>>
>>> or you can do it like this.
>>>
>>> enum : ushort
>>> {
>>>    THE=0x01;
>>>    ...
>>> }
>>>
>>> only problem is that you lose the enum name, which is nice to have if 
>>> you
>>> have conflicting names (but that shouldn't happen very often).
>>
>>
>> Thanks, I didn't realise you could have un-named enums.
>>
>> However I still think there is merit in my idea, Walter how hard would 
>> it be to have the compiler treat this:
>>
>>   fooBar(THE);
>>
>> the same as
>>
>>   fooBar(EnumName.THE);
>>
>> given that
>>
>>   void fooBar(EnumName a);
>>
>> basically tells you what to expect.
>>
>> ?
>>
>> Regan
>>
>
> The reason that it requires a fully qualified name is to prevent name 
> clashes, and to make the code more clear.  What would the compiler do if 
> you had:
>
> void fooBar(ushort s);
>
> enum Foo : ushort { one, is, the, first, number }
> enum Bar : ushort { just, one, more, time }
>
> fooBar(one); // would it be Foo.one or Bar.one?

An excellent question. The answer, this requires a fully qualified name.

> Requiring Foo.one or Bar.one provides clearer code.

I agree that in your above example the fully qualified name makes it 
clearer, but then I'm not asking to be able to use non-fully qualified 
names in situations shown by your example.

I don't believe fully qualifying makes _my_ example any clearer, nor does 
it make other similar situations any clearer.

> If you just want global constants, then use an anonymous enum, that's 
> what it's there for.

I don't want global constants specifically. I just don't want to have to 
type FooBarBaz 6 times.

I'm not suggesting abolishing fully qualified names, far from it. I'm 
simply saying in certain situations it knows what you mean without you 
having to say so. (several times)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
August 10, 2004
Re: Enums can be annoyingly verbose...
Regan Heath wrote:

> On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
> <deja@scratch-ware.net> wrote:
> 
>> Regan Heath wrote:
>>
>>> On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
>>> <kb3ctd2@yahoo.com> wrote:
>>>
>>>> or you can do it like this.
>>>>
>>>> enum : ushort
>>>> {
>>>>    THE=0x01;
>>>>    ...
>>>> }
>>>>
>>>> only problem is that you lose the enum name, which is nice to have 
>>>> if you
>>>> have conflicting names (but that shouldn't happen very often).
>>>
>>>
>>>
>>> Thanks, I didn't realise you could have un-named enums.
>>>
>>> However I still think there is merit in my idea, Walter how hard 
>>> would it be to have the compiler treat this:
>>>
>>>   fooBar(THE);
>>>
>>> the same as
>>>
>>>   fooBar(EnumName.THE);
>>>
>>> given that
>>>
>>>   void fooBar(EnumName a);
>>>
>>> basically tells you what to expect.
>>>
>>> ?
>>>
>>> Regan
>>>
>>
>> The reason that it requires a fully qualified name is to prevent name 
>> clashes, and to make the code more clear.  What would the compiler do 
>> if you had:
>>
>> void fooBar(ushort s);
>>
>> enum Foo : ushort { one, is, the, first, number }
>> enum Bar : ushort { just, one, more, time }
>>
>> fooBar(one); // would it be Foo.one or Bar.one?
> 
> 
> An excellent question. The answer, this requires a fully qualified name.
> 
>> Requiring Foo.one or Bar.one provides clearer code.
> 
> 
> I agree that in your above example the fully qualified name makes it 
> clearer, but then I'm not asking to be able to use non-fully qualified 
> names in situations shown by your example.
> 
> I don't believe fully qualifying makes _my_ example any clearer, nor 
> does it make other similar situations any clearer.
> 
>> If you just want global constants, then use an anonymous enum, that's 
>> what it's there for.
> 
> 
> I don't want global constants specifically. I just don't want to have to 
> type FooBarBaz 6 times.
> 
> I'm not suggesting abolishing fully qualified names, far from it. I'm 
> simply saying in certain situations it knows what you mean without you 
> having to say so. (several times)
> 
> Regan
> 


Well, personally, I think that Walter has far far more important issues 
than reducing the amount of copy/paste you have to do because you want 
fully-qualified enums without using fully-qualified identifiers.

The option of global constants exists for you if you're that lazy that 
you can't type an additional 10 characters to use an enum value.

If you really are that lazy, just enclose the bit you want with:

with(FooBarBaz)
{
/+ all your code you don't want to use an FQI for +/
}

You've wasted more keystrokes typing up and defending this ridiculous 
request to assist lazy coding practices than you probably will use 
typing in "FooBarBaz." in your current project.

I can see no justification for coding implicit enum resolution into the 
compiler when there are several much less ambiguous options available.

-Deja
August 10, 2004
Re: Enums can be annoyingly verbose...
Deja Augustine wrote:

> Regan Heath wrote:
> 
>> On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
>> <deja@scratch-ware.net> wrote:
>>
>>> Regan Heath wrote:
>>>
>>>> On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
>>>> <kb3ctd2@yahoo.com> wrote:
>>>>
>>>>> or you can do it like this.
>>>>>
>>>>> enum : ushort
>>>>> {
>>>>>    THE=0x01;
>>>>>    ...
>>>>> }
>>>>>
>>>>> only problem is that you lose the enum name, which is nice to have 
>>>>> if you
>>>>> have conflicting names (but that shouldn't happen very often).
>>>>
>>>>
>>>>
>>>>
>>>> Thanks, I didn't realise you could have un-named enums.
>>>>
>>>> However I still think there is merit in my idea, Walter how hard 
>>>> would it be to have the compiler treat this:
>>>>
>>>>   fooBar(THE);
>>>>
>>>> the same as
>>>>
>>>>   fooBar(EnumName.THE);
>>>>
>>>> given that
>>>>
>>>>   void fooBar(EnumName a);
>>>>
>>>> basically tells you what to expect.
>>>>
>>>> ?
>>>>
>>>> Regan
>>>>
>>>
>>> The reason that it requires a fully qualified name is to prevent name 
>>> clashes, and to make the code more clear.  What would the compiler do 
>>> if you had:
>>>
>>> void fooBar(ushort s);
>>>
>>> enum Foo : ushort { one, is, the, first, number }
>>> enum Bar : ushort { just, one, more, time }
>>>
>>> fooBar(one); // would it be Foo.one or Bar.one?
>>
>>
>>
>> An excellent question. The answer, this requires a fully qualified name.
>>
>>> Requiring Foo.one or Bar.one provides clearer code.
>>
>>
>>
>> I agree that in your above example the fully qualified name makes it 
>> clearer, but then I'm not asking to be able to use non-fully qualified 
>> names in situations shown by your example.
>>
>> I don't believe fully qualifying makes _my_ example any clearer, nor 
>> does it make other similar situations any clearer.
>>
>>> If you just want global constants, then use an anonymous enum, that's 
>>> what it's there for.
>>
>>
>>
>> I don't want global constants specifically. I just don't want to have 
>> to type FooBarBaz 6 times.
>>
>> I'm not suggesting abolishing fully qualified names, far from it. I'm 
>> simply saying in certain situations it knows what you mean without you 
>> having to say so. (several times)
>>
>> Regan
>>
> 
> 
<snip>
> If you really are that lazy, just enclose the bit you want with:
> 
> with(FooBarBaz)
> {
> /+ all your code you don't want to use an FQI for +/
> }
<snip>

I do stand corrected.  with statements only work on classes and structs.

-Deja
August 10, 2004
Re: Enums can be annoyingly verbose...
In article <opschrxff75a2sq9@digitalmars.com>, Regan Heath says...

>   //proposed method
>   fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG);

Would that work? I mean, I can see that:

#    fooBar(THE);

would work, since (assuming your proposed scheme) the compiler would be able to
infer the type of the fooBar parameter. But as for

#    fooBar(THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG);

I have to ask - what is the compile-time type of the expression:

#    THE|QUICK|BROWN|FOX|JUMPS|OVER|THE|LAZY|DOG

My guess is that the compile-time type of even the expression:

#
FooBarBaz.THE|FooBarBaz.QUICK|FooBarBaz.BROWN|FooBarBaz.FOX|FooBarBaz.JUMP|FooBarBaz.OVER|FooBarBaz.THE|FooBarBaz.LAZY|FooBarBaz.DOG

is not actually FooBarBaz, but is in fact int. Does the | operator preserve the
type of an enum? I'm not sure that it does.

Arcane Jill
(basically in support but with one or two niggling doubts).
August 10, 2004
Re: Enums can be annoyingly verbose...
On Tue, 10 Aug 2004 00:28:55 -0500, Deja Augustine <deja@scratch-ware.net> 
wrote:
> Regan Heath wrote:
>
>> On Mon, 09 Aug 2004 21:57:03 -0500, Deja Augustine 
>> <deja@scratch-ware.net> wrote:
>>
>>> Regan Heath wrote:
>>>
>>>> On Mon, 9 Aug 2004 21:49:06 -0400, Jarrett Billingsley 
>>>> <kb3ctd2@yahoo.com> wrote:
>>>>
>>>>> or you can do it like this.
>>>>>
>>>>> enum : ushort
>>>>> {
>>>>>    THE=0x01;
>>>>>    ...
>>>>> }
>>>>>
>>>>> only problem is that you lose the enum name, which is nice to have 
>>>>> if you
>>>>> have conflicting names (but that shouldn't happen very often).
>>>>
>>>>
>>>>
>>>> Thanks, I didn't realise you could have un-named enums.
>>>>
>>>> However I still think there is merit in my idea, Walter how hard 
>>>> would it be to have the compiler treat this:
>>>>
>>>>   fooBar(THE);
>>>>
>>>> the same as
>>>>
>>>>   fooBar(EnumName.THE);
>>>>
>>>> given that
>>>>
>>>>   void fooBar(EnumName a);
>>>>
>>>> basically tells you what to expect.
>>>>
>>>> ?
>>>>
>>>> Regan
>>>>
>>>
>>> The reason that it requires a fully qualified name is to prevent name 
>>> clashes, and to make the code more clear.  What would the compiler do 
>>> if you had:
>>>
>>> void fooBar(ushort s);
>>>
>>> enum Foo : ushort { one, is, the, first, number }
>>> enum Bar : ushort { just, one, more, time }
>>>
>>> fooBar(one); // would it be Foo.one or Bar.one?
>>
>>
>> An excellent question. The answer, this requires a fully qualified name.
>>
>>> Requiring Foo.one or Bar.one provides clearer code.
>>
>>
>> I agree that in your above example the fully qualified name makes it 
>> clearer, but then I'm not asking to be able to use non-fully qualified 
>> names in situations shown by your example.
>>
>> I don't believe fully qualifying makes _my_ example any clearer, nor 
>> does it make other similar situations any clearer.
>>
>>> If you just want global constants, then use an anonymous enum, that's 
>>> what it's there for.
>>
>>
>> I don't want global constants specifically. I just don't want to have 
>> to type FooBarBaz 6 times.
>>
>> I'm not suggesting abolishing fully qualified names, far from it. I'm 
>> simply saying in certain situations it knows what you mean without you 
>> having to say so. (several times)
>>
>> Regan
>>
>
>
> Well, personally, I think that Walter has far far more important issues 
> than reducing the amount of copy/paste you have to do

I agree completely. I am not suggesting this be done 'right now' if you 
had read my initial post you would notice I said ".. I kinda want some 
more opinions on the matter/idea."

> because you want fully-qualified enums without using fully-qualified 
> identifiers.
>
> The option of global constants exists for you if you're that lazy that 
> you can't type an additional 10 characters to use an enum value.
>
> If you really are that lazy, just enclose the bit you want with:
>
> with(FooBarBaz)
> {
> /+ all your code you don't want to use an FQI for +/
> }
>
> You've wasted more keystrokes typing up and defending this ridiculous 
> request to assist lazy coding practices than you probably will use 
> typing in "FooBarBaz." in your current project.
>
> I can see no justification for coding implicit enum resolution into the 
> compiler when there are several much less ambiguous options available.

Firstly my initial suggestion is not ambiguous, your example, which was 
not what I was suggesting was ambiguous. To explain, my idea:

enum FooBarBaz {
  ONE,TWO
}

fooBar(ONE);

is not any more/less ambiguous than

fooBar(FooBarBaz.ONE);

because if you're wondering what ONE is, and what it means to FooBar you 
have to lookup both the 'fooBar' function and the 'FooBarBaz' enum. In the 
case of my example, the former gives you the name of the latter.

Secondly, the point of this thread is to hear people opinions, not to 
prompt Walter into action, so, while I thank you for your opinions I take 
exception to being called "lazy" repeatedly, and for no reason except that 
you have no real argument against my idea.

Sure it's not a super important feature/idea, but it's a nice touch, one 
that so far you have given no real reasons against it, all you have said 
is:
 - that I am lazy
 - that walter has more important thing to do
 - that it is ambiguous.

to all of which I believe I have replied in a civil manner, which is more 
than I can say for you.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home