Re: passing enum value as an argument


Well, if you read the thread carefully you will see that I DID mention
Option Strict before. But even with Option Strict ON you can still pass a
value from another Enum if you cast it.

Nevertheless, because of all these comments, we are drifting away from the
point of this question, and I still stand on my ground: Refering to Enum
options without fully qualifying them defeats the purpose of having an Enum.
You might as well declare variables or constants if you dont want to go
through the trouble of qualifying names.

Cya!



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


"Jay B. Harlow [MVP - Outlook]" wrote:

> Madestro,
> |I am not sure what language you are coding in, but at least in VB.NET you
> are
> | incorrect. Here are the TRUE results:
>
> | Like I said before, ultimately, the enum evaluates to a constant, so there
> | is really no "type safety" here
>
> Your statement is True, if and only if, you are using Option Strict Off.
>
> If you use Option Strict On, than Enums are type safe as Jon suggests.
>
> I normally use Option Strict On to ensure type safety, by having compile
> time errors, rather then hard to find runtime time errors as your sample
> potentially is.
>
> Remember that Option Strict Off is the default and it allows (potentially
> dangerous) implicit casts, such as your example of the SecondEnum value to a
> FirstEnum type.
>
> | 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.
> Try your example with Option Strict On...
>
> Hope this helps
> Jay
>
> "Madestro" <me_no_like_spam_juanDOTromero@bowneDOTcom> wrote in message
> news:BA715744-5467-4F04-B142-FB51798C8BF9@xxxxxxxxxxxxxxxx
> |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 - <skeet@xxxxxxxxx>
> | > http://www.pobox.com/~skeet
> | > If replying to the group, please do not mail me too
> | >
>
>
>
.

Relevant Pages

  • RE: passing enum value as an argument
    ... Not with option strict on. ... Public Enum FirstEnum ... Shared Sub TakeSecondEnum ...
    (microsoft.public.dotnet.general)
  • RE: passing enum value as an argument
    ... > hours after your only previous reference to Option Strict? ... indeed you would have an Enum, and you WOULD have to use the same type on the ... the compiler would force you to ... >> Public sub New ...
    (microsoft.public.dotnet.general)
  • RE: passing enum value as an argument
    ... I did talk about Option Strict. ... > I clearly stated that you could CAST to the Enum type. ... > Public sub New ... > Juan Romero ...
    (microsoft.public.dotnet.general)
  • RE: passing enum value as an argument
    ... I did talk about Option Strict. ... I clearly stated that you could CAST to the Enum type. ... Public sub New ... a language can NEVER allow you to use the name ...
    (microsoft.public.dotnet.general)
  • RE: passing enum value as an argument
    ... I could cast it to the Enum. ... clearly asking for trouble (just like if you turn option strict off) - ... > Anyways, If the language allowed you to reference it directly, then you ... You would only have ambiguity problems if you'd got another ...
    (microsoft.public.dotnet.general)
Loading