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?
Name:
Anonymous2011-10-21 13:59
>>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.