Why can't switch be used for objects

[cody]

Why can't switch used for objects, at least for static readonly fields it
wold be nice.
The Jit could certainly optimize this case because the addresses of static
readonly variables are known at jit time.

The thing is that is often used my own enum classes because I usually want
to assign a userfriendly (and localizable) name to an enum member which is
automatically displayed if I add a enum member to a combobox for example.
Additionally I have helper methods for returning me a list of all or a
specific subsets of the member of the enums:

public class Color
{
public static reaonly Color Red = new Color(255,0,0);
public static reaonly Color Green = new Color(0,255,0);
// and so on

private Color(){}

public Color[] GetColors() ..
public Color[] GetGreenLikeColors() ..
public Color[] GetDarkColors() ..
public Color[] GetSystemColors() ..

Color GetByName(string name){}
Color GetByID(string name){}
}

The getXX methods work mainly using hashtables and the great thing is that
if using generics I could derive all enums from some base enum class without
having to add new getXX methods which return Color[] instead of object[].

The stupid thing is if I change some enum into my enum class I always have
to rewrite all switches into huge ugly if's.

I see no technical reason why switch shouldn' be allowed for objects.
Certainly is won't be as fast as with constant int values but anyway they
allowed strings in switch statements.

In a modern language like C# the purpose of a switch statement shouldn't be
to make a program faster but more readable.

Am I just plain stupid or is there something huge I overlooked?

[Bruce Wood]

I'm a little confused by your post, since I don't see any enums
declared anywhere in it. However, if I understand the nature of your
problem in general, then I have a question:

Why is some outside agent (some method outside the class), sifting
through your objects in an attempt to decide which enum to return? Why
doesn't the class itself supply you with its appropriate enum. For
example:

enum ColorEnum
{
Unspecified,
Red,
Green,
Blue
}

Color r = new Color(255,0,0,ColorEnum.Red);
Color g = new Color(0,255,0,ColorEnum.Green);
Color b = new Color(0,0,255,ColorEnum.Blue);

Then you just say:

ColorEnum en = g.EquivalentEnum;

No switch or ifs needed. As a general rule, classes should be designed
so that the object knows a lot about itself. If you find yourself
writing complicated tests of any kind in client code then it's a big
hint that your class isn't beefy enough. It's also a hint at a future
maintenance headache, because your client code contains business logic
that "knows too much" about your objects; such code belongs within the
class itself.

[cody]

"Bruce Wood" <br*******@canada.com> schrieb im Newsbeitrag
news:11**********************@g43g2000cwa.googlegr oups.com...

I'm a little confused by your post, since I don't see any enums
declared anywhere in it. However, if I understand the nature of your
problem in general, then I have a question:
The Color class IS my Enum. Is it not a enum like a c# enum but it works
like an enum though there are differences.
Why is some outside agent (some method outside the class), sifting
through your objects in an attempt to decide which enum to return? Why
doesn't the class itself supply you with its appropriate enum. For
example:

enum ColorEnum
{
Unspecified,
Red,
Green,
Blue
}

Color r = new Color(255,0,0,ColorEnum.Red);
Color g = new Color(0,255,0,ColorEnum.Green);
Color b = new Color(0,0,255,ColorEnum.Blue);

Then you just say:

ColorEnum en = g.EquivalentEnum;

No switch or ifs needed. As a general rule, classes should be designed
so that the object knows a lot about itself. If you find yourself
writing complicated tests of any kind in client code then it's a big
hint that your class isn't beefy enough. It's also a hint at a future
maintenance headache, because your client code contains business logic
that "knows too much" about your objects; such code belongs within the
class itself.

And how do you think to convert a ColorEnum to a Color object?

[Bruce Wood]

> The Color class IS my Enum. Is it not a enum like a c# enum but it works like an enum though there are differences.

OK... then I need some code to illustrate those "big ugly 'ifs'"
because I don't understand your original problem.

And how do you think to convert a ColorEnum to a Color object?

Well, if you were doing things that way, a static method in Color would
do the trick:

public static Color ColorForEnum(ColorEnum en)
{
}

inside there you could use a switch or set up collections by asking
each Color what enum it belonged to.

Anyway, you're not doing things that way. So, post me some code so my
poor brain can get a handle on your problem. :-)

[ozbear]

On Wed, 22 Jun 2005 01:56:34 +0200, "cody" <de********@gmx.de> wrote:

<snip>

Am I just plain stupid or is there something huge I overlooked?

The answer is yes to both questions.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Bruce Wood]

Oz,

You're a regular in the Linux forums and you lost your way, didn't you?
:-)

[ozbear]

On 22 Jun 2005 16:40:12 -0700, "Bruce Wood" <br*******@canada.com>
wrote:

Oz,

You're a regular in the Linux forums and you lost your way, didn't you?
:-)

The answer is no to both questions.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[cody]

My one and only problem is that I do *not* want to declare an extra enum
because my class already has enum semantics and I want to use it in a way I
normally would do with real enums.

The original question of me was: Is there a real reason why c# does not
support switch with objects?
"Bruce Wood" <br*******@canada.com> schrieb im Newsbeitrag
news:11**********************@g43g2000cwa.googlegr oups.com...

I'm a little confused by your post, since I don't see any enums
declared anywhere in it. However, if I understand the nature of your
problem in general, then I have a question:

Why is some outside agent (some method outside the class), sifting
through your objects in an attempt to decide which enum to return? Why
doesn't the class itself supply you with its appropriate enum. For
example:

enum ColorEnum
{
Unspecified,
Red,
Green,
Blue
}

Color r = new Color(255,0,0,ColorEnum.Red);
Color g = new Color(0,255,0,ColorEnum.Green);
Color b = new Color(0,0,255,ColorEnum.Blue);

Then you just say:

ColorEnum en = g.EquivalentEnum;

No switch or ifs needed. As a general rule, classes should be designed
so that the object knows a lot about itself. If you find yourself
writing complicated tests of any kind in client code then it's a big
hint that your class isn't beefy enough. It's also a hint at a future
maintenance headache, because your client code contains business logic
that "knows too much" about your objects; such code belongs within the
class itself.

[Bruce Wood]

1. Because it would be grossly slow.
2. Because the semantics of comparison are unclear (do you use equality
by reference, or use the Equals method, or do you allow IComparers,
or... ?)
3. Because if you need this then there is probably some other (cleaner)
way to do what you want to do... which is why I'm wondering exactly
where you need this switch statement and for what, in order to propose
an alternate design. :-)

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

1. Because it would be grossly slow.
2. Because the semantics of comparison are unclear (do you use equality
by reference, or use the Equals method, or do you allow IComparers,
or... ?)
3. Because if you need this then there is probably some other (cleaner)
way to do what you want to do... which is why I'm wondering exactly
where you need this switch statement and for what, in order to propose
an alternate design. :-)

Actually, it's not entirely unreasonable, nor does it need to be slow -
with some extra support.

I've recently been playing around with Java 1.5's enums, which allow
switching and all kinds of fun. They're much more powerful than the
..NET enums - although there are certain bits of behaviour from .NET's
"simple" enums which Java makes slightly harder.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too