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/

"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

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

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/

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

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/

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

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

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

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/