Backpfeifengesicht

German for a face that cries out for a fist in it.

As part of the "API is forever" philosophy, SWT committers spend a lot of time exploring naming, package visibility and the way an API works, a long time after the code works. There is always tension between the smallest number of classes, methods and constants needed to get the job done, consistency with similar concepts in the toolkit and the future. The future is important because "API grows like fungus", however twisting today's API for a future that may never come makes today's API cumbersome and hard to maintain. So, before an API makes it out, we've considered the likely futures and have concrete ideas about what we will do should they arise. As you can imagine, all this discussion is very stressful.

I love the fact that the Germans have a word for something I feel every once in a while.

Steve

API grows like fungus!

When you define an API, if you think you are done or have covered all the cases, you're dreaming. API grows! Fortunately, there are lots of things you can do to ensure that this can happen, without resorting to the dreaded IWhatever2's.

Consider this interface method:

public void onKeyPress(Widget sender, char keyCode, int modifiers);

What's wrong here? First off, 4-byte Unicode is coming and char's won't cut it. Secondly, suppose I want to add the concept of raw keyCode (for example, to distinguish between and unshifted 'A')? There's no place for that information. How about the concept of a forwarder (ie. this key press was forwarded to this widget from another widget) or a "doit" flag to cancel the operation? Not possible.

Fortunately, the fix is easy. The method should take an object rather than a list of parameters. The object is free to grow methods and fields without breaking the method signature.

public void onKeyPress(KeyEvent keyEvent);

Seems obvious, right? Not really. This method comes from GWT. They have shipped and cannot make these sorts of changes to this method without breaking people.

Steve