Things that are beyond me.

I am really stumbling a lot into quirks of programming languages. I mean, something like "0x0" == "0", which turns out to be a true condition in PHP is quite hilarious. I found this while trying to figure out what PHP is doing when comparing values. So that's an artificially found quirk.

But this here, this is simply beyond me:

var t = {};
t['0'] = "test";
for (k in t) {
if ('0'!==k) trace("AS sucks");
}

This is not JS, even if it looks alike. It is Actionscript 3. And you already guess what this is printing out "AS sucks". I mean come on. I am putting a string with a string key into the object and the KEY is converted to a NUMBER, just because it looks like one. YES! FFS, who is the brilliant genius came up with *that* idea? This is really one of the worst sins I have ever seen. The type coercion in JS and PHP is already one of the worst (basic) ones ever - worst because they are totally avoidable. And the benefit is zero. But THIS, this is a completely failure. This is not just a quirk - no, this means that if an object is used as a dictionary that comparing keys turns out to be a bug hole (you guess how I stumbled over that crap). It's already stupid that JS converts all keys to strings, no matter of its type, but at very least, it's consistent in that behavior. But this AS the normal behavior is plainly completely mind boggling.

Yes, I am most likely not the first one to find this out, but well... doesn't matter. Just wanted to shout this out. What a sucking failure.

Generic failure

I have recently took up the work on working out a Java server for a game after having developing countless projects in other languages. While it is quite fun to implement most parts of the server, I ran into a lot of issues when dealing with the dynamic handling of incoming data and I was forced to do some research... which made a bad day a great deal worse.

When generics were introduced years ago, I cheerfully started using them as they seemed to be a nice feature to avoid casting. However I ran into inconsistencies after a short time when creating my own classes in combination with arrays, for example:

LinkedList<T>[] arrg = new LinkedList<T>[10];

Even though it looks fine, this won't compile. The message is

Cannot create a generic array of LinkedList<T>

I was pretty surprised about this back then and nowadays I still am. After all, this works:

LinkedList<T>[] arrg = new LinkedList[10];

But then my IDE complains about type safety. The funny thing is, that it turns out that generics don't provide any real type safety at all. Mike Stone described this more closely in his blog here.

I also found a blog post of Steve Yegge which I found also interesting as he gave me some clues what the real problem is. I am quoting here the matching part since his post is pretty long:

In Java 1.0, when you pulled a String out of a Hashtable you had to cast it as a String, which was really stupid because you said

String foo = (String) hash.get(...)

You know, it's like... if you had to pick a syntax [for casting], you should at least pick one that specifies what you think it's supposed to be, not what it's becoming – obviously becoming – on the left side, right?

And everybody was like, "I don't like casting! I don't like casting!" So what did they do? What they could have done is they could have said, "All right, you don't have to cast anymore. We know what kind of variable you're trying to put it in. We'll cast it, and [maybe] you'll get a ClassCastException."

Instead, they introduced generics, right, which is this huge, massive, category-theoretic type system that they brought in, where you have to under[stand] – to actually use it you have to know the difference between covariant and contravariant return [and argument] types, and you have to understand why every single mathematical... [I tail off in strangled frustration...]

So I read the article on covariance and contravariance and funny enough, I found another even more interesting code fragment:

// a is a single-element array of String
String[] a = new String[1];

// b is an array of Object
Object[] b = a;

// Assign an Integer to b. This would be possible if b really were
// an array of Object, but since it really is an array of String,
// we will get a java.lang.ArrayStoreException.
b[0] = 1;

I have never considered doing such a thing in Java - and found this piece of code surprisingly funny as well as enlightening as it describes pretty well the problematic of arrays in an object oriented typing system.

I also found Clinton Begin blog entry interesting as he reflects as well on generics and typing.

But if one is on the rails to hell, things get worse. Clinton Begin writes

Integer a = 2;
Integer b = 2;
Integer c = 2000;
Integer d = 2000;
  
System.out.println(a==b); // true
System.out.println(c==d); // false

Now this is a bummer that I have to ponder on... What I don't get - why is the equality check evaluating true if the value is below a certain threshold?

Much to ponder on...