switch using strings

[Joshua Cranmer]

That's what i'd usually do. But thinking about it, i don't see why it's
preferable to my hypothetical class switch. What's the benefit? How does
using a visitor rather than a switch help me deliver more value to my
customer?

The visitor case is a poor man's implementation of double dispatch (I
meant this earlier when I said "dynamic dispatch"... I suppose 7 PM is
not the time to be rebutting posts...).

That has got to be the fastest abandonment of the technical high ground
i have ever seen. Did you use a sledge?

The real answer to a switch-based-on-class, I think, would be double
dispatch. However, Java doesn't really support double dispatch, and I'm
not sure whether or not it should.

It's mostly a contrived example. I mean, we do actually have some logic
almost exactly like that, but we recognise it's a mistake and are
working on getting rid of it!

I'll grant you that it is a contrived example, but one would hope that a
contrived example would be more persuasive in explaining why a feature
would be useful...

Duff's device!

Hmm, I should put that on a test and ask people what it does and why it
works. I wonder if the average on that question would be above or below 25%.

 

[Tom Anderson]

The real answer to a switch-based-on-class, I think, would be double
dispatch.

Yes, i'd agree with that.

However, Java doesn't really support double dispatch, and I'm not sure
whether or not it should.

I wouldn't say it's a high priority. I think i'd rather have it than not,
though, provided it wasn't the default - i would like method resolution to
use static parameter types, as it does now, unless i ask for double
dispatch. I had been hoping we'd get it as a free bonus from the
invokedynamic work, but evidently not.

In the absence of double dispatch (multiple dispatch, really, since
methods can have more than one parameter), i think a classy switch would
be handy from time to time.

I'll grant you that it is a contrived example, but one would hope that a
contrived example would be more persuasive in explaining why a feature
would be useful...

Er, well, i'm sure people can think of uses for it from their own
experience.

Hmm, I should put that on a test and ask people what it does and why it
works. I wonder if the average on that question would be above or below
25%.

On comp.lang.c, well above. Here, below. Bonus points for accurately
describing exactly what it was originally for.

tom

 

[Michael Wojcik]

Duff's device!

Besides the empty case and Duff's device, probably the only other
common use of fallthrough in C is when two cases share a common body,
but one has some additional preparatory step:

case 0:
prepare(foo);
case 1:
perform(foo);
break;

This is much less likely to be useful in an OO language, because it's
precisely the sort of difference that's likely to be encapsulated in
the class hierarchy.

Of course, even in non-OO languages there are many ways to abstract
this sort of thing (including building explicit polymorphism into data
structures), many of which are arguably better approaches.

 

[Roedy Green]

...which obviously won't work.
I have a series of packets coming in with a header that contains a
message name in text. I need to find a neat way to do a kind of switch
statement on the message name. Any ideas?

I just discovered project coin in JDK 1.7 supports Strings in case
labels. They could implement it like a mini enum, with a valueOf
using a HashMap or a linear or binary search depending on the size of
the table.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..

 

[Lew]

I just discovered project coin in JDK 1.7 supports Strings in case
labels. ...

Yeah, that's been mentioned in this thread several times over the last seven
days or so.

 

[Roedy Green]

Yeah, that's been mentioned in this thread several times over the last seven
days or so.

Obviously I did not read them. So what?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Refactor early. If you procrastinate, you will have
even more code to adjust based on the faulty design.
..

 

[Lew]

Obviously I did not read them. So what?

Just thought you might like to catch up with where the conversation had
already gone for a week. It looked like you weren't aware of what others had
said so I filled in the gap for you.

You're welcome.

 

[Arne Vajhøj]

Obviously I did not read them. So what?

I think it is rather arrogant to expect other people to
read ones post without oneself being willing to read
what other people post.

Arne

 

[Ian]

...which obviously won't work.
I have a series of packets coming in with a header that contains a
message name in text. I need to find a neat way to do a kind of switch
statement on the message name. Any ideas?

How about representing the strings as enums, I believe you can switch on
them?

Ian.

 

[Lew]

How about representing the strings as enums, I believe you can switch on them?

Indeed you can, Ian, and you can even use enums for a pseudo "switch-on-string".

Supplement 'valueOf(String)' with your own static 'fromString(String)' (or
similar) for "friendly" strings.

switch ( YourEnum.fromString( choiceString ) )
{ ... }

This is preferable to switching on strings even when that becomes available.

The majority of "new" Java features (for both 7 and 8) are just such pretty
wrapping paper on things already possible in Java for those willing to think
and to type.

 

[Mike Schilling]

Indeed you can, Ian, and you can even use enums for a pseudo
"switch-on-string".

Supplement 'valueOf(String)' with your own static 'fromString(String)' (or
similar) for "friendly" strings.

switch ( YourEnum.fromString( choiceString ) )
{ ... }

This is preferable to switching on strings even when that becomes
available.

The majority of "new" Java features (for both 7 and 8) are just such
pretty wrapping paper on things already possible in Java for those willing
to think and to type.

That applies to 1.5 as well, except for generics and covariant return types.

 

[Stefan Ram]

That applies to 1.5 as well, except for generics and covariant return types.

There still are several patterns, where an abbreviation
would come in handy:

final TYPE x = new TYPE(...);
-->
final x = new TYPE();
i.e., »TYPE« is implied

if( x instanceof TYPE ){ final TYPE y=( TYPE )x; ... }
-->
if( TYPE y = x ){ ... }

new INTERFACE(...)
-->
will create an instance of the first matching default
implementation class for this interface taken from a
configuration text file. Resolving this at runtime
would be more flexible, but has some security
implications, too. This should only be used when a
program indeed can run correctly with /any/
reasonable implementation of a certain interface.

 

[Lew]

There still are several patterns, where an abbreviation
would come in handy:

final TYPE x = new TYPE(...);
-->
final x = new TYPE();
i.e., »TYPE« is implied

if( x instanceof TYPE ){ final TYPE y=( TYPE )x; ... }
-->
if( TYPE y = x ){ ... }

new INTERFACE(...)
-->
will create an instance of the first matching default
implementation class for this interface taken from a
configuration text file. Resolving this at runtime
would be more flexible, but has some security
implications, too. This should only be used when a
program indeed can run correctly with /any/
reasonable implementation of a certain interface.

As Java evolves, apparently we have to reach deeper and deeper into the bottom
of the barrel for things to change. I guess we have always to find something
to "improve"?

 

[Ian]

That applies to 1.5 as well, except for generics and covariant return
types.

Although I haven't actually used it . . . yet.

I think I would find the executor framework quite useful.

So, apart from <snip> what have the Romans done for us?

Ian.

 

[Robert Klemme]

Or use a multiple-exit method:

int String2MessageIndex(String messName) {
if (messName.equals("This")) { return 0; }
if (messName.equals("That")) { return 1; }
if (messName.equals("The other")) { return 2; }
if (messName.equals("Something")) { return 3; }
if (messName.equals("Different")) { return 4; }
// As many more as needed ...

// Default return value.
return UNRECOGNIZED_MESSAGE;
}

Well, this would be better implemented using a Map. And even if you
need to execute code you can define an interface (or base class) and
retrieve it from the Map via the String as key. Then execute it.

Cheers

robert

 

[Lew]

Well, this would be better implemented using a Map. And even if you need to
execute code you can define an interface (or base class) and retrieve it from
the Map via the String as key. Then execute it.

Maps are simple to implement, not really necessary for short lists but not
harmful and quite useful as the lists get larger.

Arguably they're harder to understand than if-chains or multiple-exit methods,
considering maintenance perspectives.

Pushing the decision into a subroutine contains the effort either way to one
only those who truly care will ever see.

But could be overkill.

Pretty much all the suggested idioms are useful and irreproachable. One might
find one or another suitable as the situation offers.

 

[Ian]

Sorry, I couldn't figure this out - which "it" have you not used yet?

"it" - forward reference to the executor framework, which is a library
feature rather than a language one, so let's just forget I mentioned it
eh

Ian.

 

[javax.swing.JSnarker]

The so-called "diamond operator" is a case in point.

What so-called "diamond operator"?

I expect it to be about as helpful as autoboxing
(a feature I eschew) and perhaps as dangerous

Since when is autoboxing "dangerous"?

--

 

[Paul Cager]

What so-called "diamond operator"?

This one: http://download.oracle.com/javase/tutorial/java/generics/gentypes..html

Since when is autoboxing "dangerous"?

Since Java 1.5, I believe.

 

[Lew]

This one:http://download.oracle.com/javase/tutorial/java/generics/gentypes.html



Since Java 1.5, I believe.

That's correct.