I'm writing a class with a method that will accept 1 of 3 items listed in an
enum. Is it possible to pass the item name without the enum name in your
calling statement?

EXAMPLE:

public enum EnumName
FirstValue = 1
SecondValue = 2
ThirdValue = 3
end enum

CURRENTLY DOING THIS:
ObjectName.MethodName(EnumName.FirstValue)

WANT TO DO THIS:
ObjectName.MethodName(FirstValue)

You can add an imports statement to the top of your code that imports
the enum.

Imports RootNamespace.MyEnum

Public Enum MyEnum As Integer
FirstValue = 1
SecondValue = 2
ThirdValue = 3
End Enum

=?Utf-8?B?R2xlbm4gVmVuemtl?= <(E-Mail Removed)>
wrote in news:390378C0-2925-49F1-B075-(E-Mail Removed):
> CURRENTLY DOING THIS:
> ObjectName.MethodName(EnumName.FirstValue)
>
> WANT TO DO THIS:
> ObjectName.MethodName(FirstValue)

No - its part of its "namespace" if you will and prevent conflicts or requiring prefixes on each
enum value. Why would you want to do this?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/

Hi there,

That would defeat the purpose of having an Enum. you might as well create
three variables then.

--
Juan Romero
-----------------------------------------
The successful person has the habit of doing the things failures don't like
to do.
E.M. Gray


"Glenn Venzke" wrote:

> I'm writing a class with a method that will accept 1 of 3 items listed in an
> enum. Is it possible to pass the item name without the enum name in your
> calling statement?
>
> EXAMPLE:
>
> public enum EnumName
> FirstValue = 1
> SecondValue = 2
> ThirdValue = 3
> end enum
>
> CURRENTLY DOING THIS:
> ObjectName.MethodName(EnumName.FirstValue)
>
> WANT TO DO THIS:
> ObjectName.MethodName(FirstValue)
>
>
>

Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> That would defeat the purpose of having an Enum. you might as well create
> three variables then.

I don't see how it would defeat type safety, which is the purpose of
having an enum from my point of view. So long as you couldn't pass in a
value from a *different* enum, it would be fine. I don't see any reason
why the language couldn't allow it.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

The value of an Enum option evaluates to a constant, so technically, I COULD
pass a value from another Enum, so long as Option Strict is OFF and even if
it was on, I could cast it to the Enum. The only useful things in my opinion
about Enums is that they they help you code fast (intellisense), you dont
have to remember what each value represents and it provides a range of
acceptable values. I don't really see any type safety benefits.

Anyways, If the language allowed you to reference it directly, then you
would have ambiguity problems with variables declared in the same scope and
therefore WOULD defeat the purpose of having an Enum in the first place.

From MSDN:

------------------------------------------

Enumeration variables are variables declared to be of an Enum type.
Declaring a variable in this way helps you to control the values you assign
to it. If Option Strict is On, you can assign only enumeration members to the
enumeration variable. In this case, you can use the CType keyword to
explicitly convert a numeric data type to an Enum type.

You must qualify every reference to an enumeration member, either with the
name of an enumeration variable or with the enumeration name itself. For
example, in the preceding example, you can refer to the first member as
SecurityLevel.IllegalEntry, but not as IllegalEntry.

------------------------------------------

Good luck!


--
Juan Romero
-----------------------------------------
The successful person has the habit of doing the things failures don't like
to do.
E.M. Gray


"Jon Skeet [C# MVP]" wrote:

> Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> > That would defeat the purpose of having an Enum. you might as well create
> > three variables then.
>
> I don't see how it would defeat type safety, which is the purpose of
> having an enum from my point of view. So long as you couldn't pass in a
> value from a *different* enum, it would be fine. I don't see any reason
> why the language couldn't allow it.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> The value of an Enum option evaluates to a constant, so technically, I COULD
> pass a value from another Enum, so long as Option Strict is OFF and even if
> it was on, I could cast it to the Enum.

Yes, if you want to get around the type safety, you can. I don't see
how that makes it less valuable to have enums which can be safely
passed around if you *don't* deliberately break things, nor would
inferring the type from the method parameter break that type safety.

> The only useful things in my opinion about Enums is that they they
> help you code fast (intellisense), you dont have to remember what
> each value represents and it provides a range of acceptable values. I
> don't really see any type safety benefits.

Try getting the values of FileAccess, FileMode, FileShare etc the wrong
way round on a call to the FileStream constructor. The compiler tells
you - so long as you haven't *deliberately* started casting from one
enum type to another via their underlying type. If you do that, you're
clearly asking for trouble (just like if you turn option strict off) -
but I rather like the fact that I get an error when I've *mistakenly*
got the parameters the wrong way round.

> Anyways, If the language allowed you to reference it directly, then you
> would have ambiguity problems with variables declared in the same scope and
> therefore WOULD defeat the purpose of having an Enum in the first place.

You would only have ambiguity problems if you'd got another
member/variable/whatever with the same name. At that point, the
compiler could force you do disambiguate. What's the problem?

(Quoting what the language specification says *now* doesn't stop the
language changing - C# is doing exactly that when it comes to
delegates, where the delegate type is inferred in v2.0 despite it not
being inferred in the currently released version.)

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

That is exactly the point. I encourage Enums. Going back to the question, the
user is trying to use them without fully qualifying them which in turn
results in "defeat of the purpose" like I mentioned before.
--
Juan Romero
-----------------------------------------
The successful person has the habit of doing the things failures don't like
to do.
E.M. Gray


"Jon Skeet [C# MVP]" wrote:

> Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> > The value of an Enum option evaluates to a constant, so technically, I COULD
> > pass a value from another Enum, so long as Option Strict is OFF and even if
> > it was on, I could cast it to the Enum.
>
> Yes, if you want to get around the type safety, you can. I don't see
> how that makes it less valuable to have enums which can be safely
> passed around if you *don't* deliberately break things, nor would
> inferring the type from the method parameter break that type safety.
>
> > The only useful things in my opinion about Enums is that they they
> > help you code fast (intellisense), you dont have to remember what
> > each value represents and it provides a range of acceptable values. I
> > don't really see any type safety benefits.
>
> Try getting the values of FileAccess, FileMode, FileShare etc the wrong
> way round on a call to the FileStream constructor. The compiler tells
> you - so long as you haven't *deliberately* started casting from one
> enum type to another via their underlying type. If you do that, you're
> clearly asking for trouble (just like if you turn option strict off) -
> but I rather like the fact that I get an error when I've *mistakenly*
> got the parameters the wrong way round.
>
> > Anyways, If the language allowed you to reference it directly, then you
> > would have ambiguity problems with variables declared in the same scope and
> > therefore WOULD defeat the purpose of having an Enum in the first place.
>
> You would only have ambiguity problems if you'd got another
> member/variable/whatever with the same name. At that point, the
> compiler could force you do disambiguate. What's the problem?
>
> (Quoting what the language specification says *now* doesn't stop the
> language changing - C# is doing exactly that when it comes to
> delegates, where the delegate type is inferred in v2.0 despite it not
> being inferred in the currently released version.)
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> That is exactly the point. I encourage Enums. Going back to the question, the
> user is trying to use them without fully qualifying them which in turn
> results in "defeat of the purpose" like I mentioned before.

But it *doesn't* defeat the purpose. It doesn't stop the compiler from
noticing if he's trying to pass in a value which isn't in the enum. It
doesn't stop the compiler from noticing if he's trying to pass in a
value from another enum, whether explicitly or not.

If you had two enums, FirstEnum with values Foo, Bar, Baz and
SecondEnum with values Fred, George, Harry, and two methods:

TakeFirstEnum (FirstEnum x)
TakeSecondEnum (SecondEnum y)

then the following would be valid calls:
TakeFirstEnum(Foo)
TakeFirstEnum(FirstEnum.Foo)
TakeSecondEnum(Fred)
TakeSecondEnum(SecondEnum.Fred)


and the following would be invalid calls:
TakeFirstEnum(Fred)
TakeFirstEnum(SecondEnum.Fred)
TakeSecondEnum(Foo)
TakeSecondEnum(FirstEnum.Foo)

So there's still just as much type safety there as there was before -
which would *not* be the case if he'd just gone with ints rather than
enums in the first place. For that reason, I fail to see how it defeats
the purpose.

The only times it would cause potential for confusion would be where
there was an overloaded method where the differing parameter types were
both enums. In that case, the compiler could force the developer to
explicitly state which enum he wanted to use.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I am not sure what language you are coding in, but at least in VB.NET you are
incorrect. Here are the TRUE results:

TakeFirstEnum(Foo) --> FAILS
TakeFirstEnum(FirstEnum.Foo) --> SUCCEEDS
TakeSecondEnum(Fred) --> FAILS
TakeSecondEnum(SecondEnum.Fred) --> SUCCEEDS

TakeFirstEnum(Fred) --> FAILS
TakeFirstEnum(SecondEnum.Fred) --> SUCCEEDS
TakeSecondEnum(Foo) --> FAILS
TakeSecondEnum(FirstEnum.Foo) --> SUCCEEDS

Like I said before, ultimately, the enum evaluates to a constant, so there
is really no "type safety" here, except for the type of the constant and the
range of valid values the enum provides. Because of this, I could call the
first function with a value from the second Enum so long as it evaluates to a
value within the range of the first Enum. What I cannot do however is call
one of the values of the Enum without fully qualifying it because once again,
like I said before) you would run into ambiguity problems.

It may not be the case in the language you are using, but it certainly is
the case with VB.NET. Try it, you will see.

--
Juan Romero
-----------------------------------------
The successful person has the habit of doing the things failures don't like
to do.
E.M. Gray


"Jon Skeet [C# MVP]" wrote:

> Madestro <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote:
> > That is exactly the point. I encourage Enums. Going back to the question, the
> > user is trying to use them without fully qualifying them which in turn
> > results in "defeat of the purpose" like I mentioned before.
>
> But it *doesn't* defeat the purpose. It doesn't stop the compiler from
> noticing if he's trying to pass in a value which isn't in the enum. It
> doesn't stop the compiler from noticing if he's trying to pass in a
> value from another enum, whether explicitly or not.
>
> If you had two enums, FirstEnum with values Foo, Bar, Baz and
> SecondEnum with values Fred, George, Harry, and two methods:
>
> TakeFirstEnum (FirstEnum x)
> TakeSecondEnum (SecondEnum y)
>
> then the following would be valid calls:
> TakeFirstEnum(Foo)
> TakeFirstEnum(FirstEnum.Foo)
> TakeSecondEnum(Fred)
> TakeSecondEnum(SecondEnum.Fred)
>
>
> and the following would be invalid calls:
> TakeFirstEnum(Fred)
> TakeFirstEnum(SecondEnum.Fred)
> TakeSecondEnum(Foo)
> TakeSecondEnum(FirstEnum.Foo)
>
> So there's still just as much type safety there as there was before -
> which would *not* be the case if he'd just gone with ints rather than
> enums in the first place. For that reason, I fail to see how it defeats
> the purpose.
>
> The only times it would cause potential for confusion would be where
> there was an overloaded method where the differing parameter types were
> both enums. In that case, the compiler could force the developer to
> explicitly state which enum he wanted to use.
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>