Ketan's Musings

I logged in into the EclipseCon website to propose a BoF. I wanted to login into the submission system and could not manage to do so after clicking about 4 links and had to open up gmail to pull some links out of my email.

I’d expect a ‘login’ link to be clearly visible on the eclipsecon website.

Here’s what I did:
1. Click on the “Propose a BoF” link
2. Look around for a login link that I can click, nothing
3. There is a ‘register’ link click on that, takes you to the same page
4. Nothing, open gmail and find a link to the submission system

I’ve filed a bug about this. The eclipsecon website could also use some love to improve usability.

This just made my day!

 _________________________________________
/ How much net work could a network work, \
\ if a network could net work?            /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Given git and mercurial the title should have been “Are you still using subversion?”; but anyway.

SVN 1.5 has been around for a while now, and provides a range of new features that help improve the overall experience and makes SVN suck less.

I’ve opened this bug to request that projects that want to migrate to svn 1.5 at eclipse.org have the option to do so. The existing SVN is running on a SVN 1.4.0. Please drop in your comments on this bug.

This post is in addition to Boris’ post about accidental complexity of APIs, and problems around evolving them over time, and a a summary of some comments on that blog post.

Dependency injection over Service Locator.

Each one has their own baggage of merits and de-merits.

DI also adds to better design, so that classes do not start doing Platform.getExtensionRegistry().getConfigurationElementsFor(EXTENSION_POINT_ID).createExecutableExtension(myProperty) in the middle of nowhere, and there’s no way that I can start testing them unless the tests put something in the registry. Service Locator makes provisions for the some of the extensibility that eclipse needs. Injecting objects that locate services into objects that need these services seems to be a right thing to do:

Here’s an example of what we do: makes for easy testing because it is now possible to mock the interface out for testing the object.

public class FooBarFacade {
  public FooBarFacade(IConfigurationElement driver) {
    options = (IFooBarOptionsOptions) driver.createExecutableExtension(OPTIONS_EXTENSION_POINT);
    optionsComposite = (IFooBarOptionsComposite) driver.createExecutableExtension(OPTIONS_UI);
    optionsInitializer = (IFooBarInitializer) driver.createExecutableExtension(INITIALIZER);
  }
}

Interfaces with getter/setter methods

The other point that always strikes me in the API are some really huge interfaces with get/set methods. Clearly the interface/implementation is doing more than that, using abstract classes is probably a good thing to do in such cases (more so, if there’s going to be just one implementation of the interface anyway)

Why do we need getters and setters anyway ? Do they not break encapsulation ? There’s two schools of opinions I’ve come across here. One that likes to follow the javabeans specfications. The other that says hates getters and setters for the reason that objects then tell you who their friends are (Disclosure: I belong to such a group). Objects should expose behavior and not their friends that may help you out.

Law of Demeter

The Law of Demeter says “talk to your immediate friends”. getA().getB().getC().doSomething is probably a bad thing to do.

Don’t confuse your dog. Asking a dog to walk its legs is easier(and less confusing) than asking the dog for it’s legs and then making them walk.

Singletons and the law of demeter

I’m always having to do something like:

PlatformUI.getWorkbench().getActiveWorkbenchWindow().getWorkbench().doSomething();
IJavaProject p = JavaCore.create(ResourcesPlugin.getWorkspace().getRoot().getProject("foobar"));

So much so that I’ve now got templates for all such APIs. Why not just:

Workbench.getActiveWorkbench().doSomething();
IJavaProject p = JavaCore.createProject("foobar");

In Conclusion: How much API is “good enough” API ?

Returning the legs of a dog is an easier thing to do, and let clients manage the walking, but heck, I can’t imagine anything I’d want to do with a dog’s legs other than to walk, so I might was well want to ask the dog to walk itself.

This is certainly not a solved problem. I prefer to follow a simple rule. Provide just about enough API to make 80% of the users happy. Provide just about enough extensibility to make the other 20% happy, just in case someone wants to make the dog walk backwards!

For the impatient:
Direct download link: https://sourceforge.net/project/showfiles.php?group_id=188411&package_id=220519&release_id=622752

Update site: http://swtbot.sourceforge.net/latest/update-site/

SWTBot 1.2.0 is the 3rd of the 1.x releases of SWTBot was released last night, and there have already been about 200 downloads by the time of writing this blog post.

SWTBot has always believed in release early release often mantra, and pushes out nightly builds out of CruiseControl. From the download stats I’m looking at, there are more downloads of the nightly build than the ‘stable’ available on the sourceforge mirrors.

The highlight of the release is support for view menus and view toolbar.

Thanks to the contributors and adoptors, for patches, criticism, and suggestions for improvement. The release has fixed about 42 issues.

Read more on the detailed release notes and the changelog.