Why SWT, Why?

So in SWT there is this thing called a KeyListener.

One might expect something called a KeyListener to listen to events on keys. Well, you'd be right, unless you consider the CTRL or the SHIFT keys to be keys. According to the KeyListener, they are just state modifiers, and as such, KeyEvents are not thrown to registered KeyListeners when they are pressed. Weird huh? To capture those events you need to use the untyped KeyUp and KeyDown listeners. And to think, that's not even my rant for today.

Ahem...

If you register a KeyUp or a KeyDown listener to a Shell, you might expect that to provide events when you press keys independent of which component on the Shell has focus currently. Of course, you'd be wrong if you thought that. Assuming that you have, let's say, 5 widgets in a Shell, you need to tab 5 times (since SWT assigns initial widget focus to the first widget on the Shell). Then you can receive all the events you want on the Shell, until focus goes back to one of the other widgets. Oh, oh...I have a question!!!! HOW IS THAT USEFUL IN ANY APPLICATION?!?!?! It seems like a bad easter egg to add to your apps which are otherwise devoid of behaviour that makes no sense. Apparently no one ever wants to know if you are ctrl-clicking on something. And there could be some argument against ever having to do that....assuming of course, that SelectionEvent did what it was supposed to on all widgets and provided the key-modifier as a stateMask.

So here's the problem. You want to listen for keystrokes and you don't care which widget is receiving them. Let's say you want to display a generic help dialog if the user presses F1 like in the old days. Obviously, you don't want to have to register key listeners on every widget you add to your GUI. That would be stupid, ugly code, that would be painfully annoying to maintain. You might think that registering the listener on the Display might work. But it doesn't. Maybe you have to press tab one more time to receive keystroke events for that.

Ugh....I need a break.

# posted by Jesse Wilson on Wednesday, March 09, 2005  4 comments   post a comment

An idea: auto-unboxing

Primitive Collections
I'm aware of at least two libraries for Java that provide collections for each of the six primitive types. So instead of storing Integer Objects in an ArrayList, you get to store int primitives in an IntArrayList. This saves RAM and it speeds things up. It's a clever optimization.

But this optimization is not very Java-ish. Where's the reusable in reusable collections when we need seven of them? It is a terrible violation of the Don't Repeat Yourself mantra.

Autoboxing
Java 5 introduced a new feature for using primitive types with old-school Object collections. It's called autoboxing and basically it allows you to replace this:

    List myList = new ArrayList();
    myList.add(new Integer(867));

with this:

    List myList = new ArrayList();
    myList.add(867);

This is simple syntactic sugar. The compiler implicitly adds the new Integer() for you.

Idea: Auto-unboxing
What if Java supported primitives with generics? This could be implemented in the compiler: ArrayList<T> could be converted into all of List<int>, List<short> etc. This would require seven .class files, which is already necessary for the other primitive collections implementations. But it would require only a single .java file.

Some problems
Collections classes use some methods only found in Object.class such as hashCode, equals() etc. This would need fixing with some unnatural hackery. The compiler would also need to know when to compile such a primitive generic class.

# posted by Jesse Wilson on Sunday, March 06, 2005  1 comments   post a comment