Why does java not allow String objects to be used in the switch/case statements? Couldn't the compile invoke hashcode() on those strings thus producing a unique integer value to represent the constant in the cases?
>>7 like a month
Implying that it is somehow ready for production because of it's maturity. QA is calling and they want to talk to your boss... about you.
Enjoy your unemployment.
Sounds like you're just comparing each char to each other also and seeing if they match up.
Name:
Anonymous2011-10-21 1:37
You could create an interface that has only one member function, which takes as arguments everything that the switch statement needs to know, and then make instances of anonymous classes that implement the interface, and then insert these code handlers as values in a hash table, where the keys are the strings.
static void final public package javaFunctionFNJavaHelper(String value, String blah) {
value = value + blah;
switch(value) {
case "Java":
System.out.println("merpa " + value);
break;
case "Is":
System.out.println("derpi " + value);
break;
case "Fun":
System.out.println("dapity " + value);
break;
case "Is it Not?":
System.out.println("dooooo " + value);
break;
default:
System.out.println("Go fuck yourself.");
break;
}
}
Can be implemented very compactly with:
Interface MyHandler
{
public void exec(String value);
}
class MySwitchHandler implements MyHandler {
public SwitchHandler() {
this.table = new HashTable<String, MyHandler>();
this.defaultCase = null;
}
javaFunctionFNJavaHelper(String value, String blah) {
MySwitchHandler switchStatement = new MySwitchHandler();
switchStatement.putCase("Java", new MyHandler() {
public void exec(String value) {
System.out.println("merpa " + value);
}
});
switchStatement.putCase("Is", new MyHandler() {
public void exec(String value) {
System.out.println("derpi " + value);
}
});
switchStatement.putCase("Fun", new MyHandler() {
public void exec(String value) {
System.out.println("dapity " + value);
}
});
switchStatement.putCase("Is it Not?", new MyHandler() {
public void exec(String value) {
System.out.println("dooooo " + value);
}
});
switchStatement.putDefaultCase(new MyHandler() {
public void exec(String value) {
System.out.println("Go fuck yourself");
}
});
switchStatement.exec(value);
}
And any language that supports both easy syntax for hash tables and closures, you can do this:
function make_switch_statement(case_table, default_case)
meta_table = {__index = function(tab, key)
local value = rawget(tab, key)
if value == nil then
return default_case
else
return value
end
end}
setmetatable(case_table, meta_table)
return case_table
end
function woop(value)
print(make_switch_statement({
Lua = function()
return 'merki '..value
end,
Is = function()
return 'derpity '..value
end,
Fun = function()
return 'dipity '..value
end,
["Is it Not?"] = function()
return 'dooooo '..value
end,
}, function()
return 'Go have fun with yourself.'
end)[value]())
end
woop('Is') -- prints derpity Is
woop('Waba') -- print Go have fun with yourself.
Name:
Anonymous2011-10-21 2:39
>>25
Cleaning floors is wasteful and timeconsuming.
Just buy some cockroaches and they'll automatically eat it up.
Plus, you get free pet food.
Name:
Anonymous2011-10-21 6:48
>>28
You might want to consider using the Runnable interface for your MyHandler so that you can integrate better with legacy code.
Name:
Anonymous2011-10-21 6:56
As promised here is my C string switch:
/*
strswitch.h
Written in 2004 by Anonymous.
ENTERPRISE-GRADE C
*/
#ifndef _STRSWITCH_H
#define _STRSWITCH_H
#include <stdlib.h>
#include <string.h>
void *strswitch_var;
int strswitch_loop;
int strswitch_enter;
x=2; can you do this in Cee?
lolwut=function(){return 2}
switch(x){
case 1.01001: ;;break;
case "Sepples":;;break;
case 0:;;break;
case x:;window.title+='1';
case lolwut():;window.title+="2";break;
default:;;break;
}
nice, but I'd add __thread or something similar for thread safety
Name:
Anonymous2011-10-21 10:06
>>35
yeah i did know it wasn't thread safe, but didn't know about the __thread .. I had consider some kind of switch where you pass in the struct for the internal vars, but that wouldn't be so clean. (Lol like anyone would ever use it)
>>28
The problem here is that your example isn't good. In it, there's not actually any variable functionality, just variable strings. This is obvious in the Lua example where all the functions are anonymous and follow a common pattern. For instance, you could implement the lua thing with:
local printy =
{
Lua = merki,
Is = derpity,
Fun = dipity,
["Is it Not?"] = "dooooo"
}
function woop(value)
print(
(printy[value] or "Go have fun with yourself.")
.." "..value)
end
because there's no variation on the fact that the thing is printing and concatenating.
Remember, what you want to do is describe -out- patterns, not describe -in- patterns.
>>31
using global variables (not thread safe, can cause linking conflicts if you use this function from more than one module)
redefining standard keywords
using for with a global variable instead of do...while(0)
using stringification macros on already quoted strings and then removing the quotes at runtime
making copies of constant strings on every comparison just to remove the quotes
stringifying NULL pointers
using your own function instead of writing macros to use strcmp()
because string-based switch/case is a compiler thing.
a language that defines a stringtype as part of the language can easily do primitive string comparison as opcodes.
D is one of the languages who define a string type as part of the language (C++ is *not* one of those; std::string is a class wrapper around char arrays).
so, D is basically able to do something like this (highly simplified pseudo assembly):
compare "foo", "foo"
jump_if_equal $1
Above code also works because information like stringlength is also part of said builtin stringtype in D.
Languages like C, C++ or Java, who don't define a stringtype as part of their language, however, would have to compare each and every single byte of each operand string, which is not only cpu intensive, at least compared to integer comparison, but also something that depends on how the operand strings are terminated. imagine one of the strings isn't nullterminated...
Thanks, using the or is a lot more succinct and easy to read than the metatable way I used, and factoring the values out is nice. I only included the values inside of the functions to show that the functions had the ability to access and mutate variables in the outer function's local scope. This is a lot more difficult to pull off in Java. You can get lexical closures for final variables, which would let the case functions access values in the outer scope (which you would have to assign into final variables), but they would not be able to mutate them. So you would either have to take advantage of their return values somehow, or pass in references to objects for them to operate on. It's never really a switch and case statement, but it could still be useful for some things, but it would never be a convenient syntactical structure. It could instead be something that is constructed once, and then passed around and used.
Name:
Anonymous2011-10-22 1:26
>>15
[quote]When you hash an input in any hash function it doesn't always return unique values, two different input might return the same value.[/quote]
ftfy
Name:
Anonymous2011-10-22 1:44
Bruteforce (aka frozenvoid) way of dealing with such problems:
Just loop over array of strings and strcmp them all.
No pointers or malloc like >>31
>>48
actually in Java you can mutate closed over variable by putting them in a final array of size 1 and mutating the content of that array. (try it; it works) final just means that the variable can't be rebound, not that the value is immutable.
>>56
yep, or calling a set function or writing to a db or doing any other side effect. My understanding is that the final requirement isn't even based on a technical limitation. It's just more of Java's "get in your way as much as possible" design philosophy.