C# Switch statement

[Duncan .McNutt]

You have no idea what I have affiliations with so bite me little man

 

[Eric Gunnerson [MS]]

It's a feature vs. complexity thing.. While we agree that there are cases
where case ranges are useful, we don't think that their usefullness above
what you get with a simple series of if statements outweighs the increase in
complexity.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Duncan .McNutt]

Complexity for whom?

--

Duncan McNutt
Microsoft Product Deactivation Team
--

It's a feature vs. complexity thing.. While we agree that there are cases
where case ranges are useful, we don't think that their usefullness above
what you get with a simple series of if statements outweighs the increase in
complexity.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Duncan McNutt [FTSE].]

So a little thing like that that may aid code readability is not good but
adding crap like Lambada functions (anonymous methods) and partial types (
to aid splitting source files) that is good?

You have the BCLs make an entire pigs mess of VSplits and HSplits and you
say thats good?

Yet adding a simple thing like ranges into a case in the switch construct is
bad because you cant be assed to handle the complexity?

Pass the bong.


--

Duncan McNutt
Microsoft Product Deactivation Team
--

It's a feature vs. complexity thing.. While we agree that there are cases
where case ranges are useful, we don't think that their usefullness above
what you get with a simple series of if statements outweighs the increase in
complexity.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Duncan McNutt [ FTSE ]]

Sign of a good person is admiting they made mistakes and learnt from them.

Hiding them is just weak.

--

Duncan McNutt
Microsoft Product Deactivation Team
--

If you've been coding in C for 8 years you have made this mistake, even if

you don't remember or are too macho to admit it.

 

[Edward Yang]

If you've been coding in C for 8 years you have made this mistake, even if

you don't remember or are too macho to admit it.

No, I never made such a mistake as far as I can remember.

Keep on pratising your spelling, Edward!

Thanks for you encourage!

 

[Edward Yang]

Hi,


Maybe YOU don't (doubtful), but many people do. Hence the design decision.

Pete, note that many != all!

 

[Austin Ehlers]

It's a feature vs. complexity thing.. While we agree that there are cases
where case ranges are useful, we don't think that their usefullness above
what you get with a simple series of if statements outweighs the increase in
complexity.

I agree. However, what about adding syntax like this:

switch (num)
{
case 1 to 5:
//code
break;
}

and translate it to the appropriate IL as if it were written like:

switch (num)
{
case 1:
case 2:
case 3:
case 4:
case 5:
//code
break;
}

As this allows increased readability and is easily maintainable?

Thanks,
Austin Ehlers

 

[Duncan McNutt [FTSE]_]

That is complex??


But theyre adding Lambada funtions (anonymous methods) and Partial types!!!

Thats even MORE complex and POINTLESS !!!

 

[Peter Vidler]

but I do NOT remember I ever made a mistake with case-break's.

Pete, note that many != all!

True, but language features should be designed around what many people will
find useful. Requiring a break or goto statement means you will get a
compile time error.. the alternative is an annoying-to-debug runtime
error -- which would you prefer? I would rather not debug a runtime error
just so the fraction of programmers who never make these mistakes will not
be so irritated with the switch statement (they can just use if-else if they
don't like it).

It should be noted that this is generation of a compile time error is
reminiscent of C++ (where strong typing generated compile time errors, and C
would only produce runtime errors). It's just taken one step further.

Pete

 

[Duncan McNutt .[FTSE]]

yeah i know its a joke duh


Lambda functions will lead to spagheti code, look at the use of them today
in other languages... Dont be so nieve that it wont be.

yes there are places when they may help but I really am worried about the
misuse of them.

Seems to be in the next release they will be added.

Same for partial types, if you need those, think about the design.

Generic types however are long overdue.

 

[craig]

Amen.

I agree. However, what about adding syntax like this:

switch (num)
{
case 1 to 5:
//code
break;
}

and translate it to the appropriate IL as if it were written like:

switch (num)
{
case 1:
case 2:
case 3:
case 4:
case 5:
//code
break;
}

As this allows increased readability and is easily maintainable?

Thanks,
Austin Ehlers

 

[Eric Gunnerson [MS]]

Both partial types and anonymous methods allow us to deal with situations
where C# does not work very well, and therefore the benefit that they bring
is higher than the benefit that case ranges would bring.

Partial types will let us segregate Windows Forms code into
designer-generated code and user code. That will make the model much easier.
There are other scenarios, but that's the primary one.

Anonymous methods are very useful in a case where you need a small bit of
code to pass as a delegate. If you put it in a separate method, you end up
with a disconnect between the small bit of code and where it's actually
used, which makes it harder to understand what's going on. If used for
scenarios such as this, anonymous methods will make your code more readable.

There is the chance for abuse with both features.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

So a little thing like that that may aid code readability is not good but
adding crap like Lambada functions (anonymous methods) and partial types (
to aid splitting source files) that is good?

You have the BCLs make an entire pigs mess of VSplits and HSplits and you
say thats good?

Yet adding a simple thing like ranges into a case in the switch construct is
bad because you cant be assed to handle the complexity?

Pass the bong.


--

Duncan McNutt
Microsoft Product Deactivation Team
--

It's a feature vs. complexity thing.. While we agree that there are cases
where case ranges are useful, we don't think that their usefullness above
what you get with a simple series of if statements outweighs the

increase

 

[Eric Gunnerson [MS]]

I'd have to see some actual code to understand how common this was and
whether it made sense to have a syntax for it. If it were only cases 1 - 5,
you'd obviously write it with a single-clause if. If there are a lot more
cases, I might be persuaded that it would be clearer to have a range. It
would take a fair bit of data to understand what people were really doing
and what the result of a new feature would be.

My experience is that switch statements are fairly rare in OO code.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Tillie]

Nope and you don't seem to want to tell us.
However, I saw you recommend somewhere to someone who lost his XP serial to
"get a key generator."
I cannot imagine someone from MS telling that.

Greetz,
-- Rob.