work. life. open source. diatribes.

I like the beginning of new releases because it gives you time to reflect on things you couldn’t do during the crazy end game days. One of those things you couldn’t really do was refactor. I like refactoring for multiple reasons…

It allows you to clean up code and strive for simplicity

Sometimes allows you to further modularize your code

You find instances of code that shouldn’t be referencing certain things

It has a side effect of possibly bringing on new contributors…

and so on…

I don’t like refactoring for multiple reasons…

refactoring a bunch of packages when all your NLS strings are in one sucks

refactoring a bunch of packages when dealing with a central image registry sucks

I’m excited to see that already for 3.5M1, we will have a couple refactorings in the Eclipse SDK:

This is exciting because it now allows people to take advantage of the core Compare code without dragging in the UI. In the past, the core and UI code were all in one plug-in (org.eclipse.compare). This wasn’t good for people who wanted to run compare code headlessly and also people that just wanted to take advantage of the ability to diff things in another context.

On the PDE side of things, I finally decided to refactor out the User Assistance (UA) tooling into separate plug-ins. I did this for two selfish reasons… (1) the PDE core and ui plug-ins were getting big… (2) I wanted to bring on another contributor to PDE to help maintain and grow the user assistance tooling in Eclipse. I don’t think there’s anything wrong with that ;)?

Anyways, I highly recommend people to look now and reflect on what they can possibly refactor out for the benefit for the wider Eclipse community. For the eclipse community, it’s a good time to bug Eclipse developers to refactor things that you always wanted… or better yet… provide patches to move things along quicker.

Share this:

Related

Did somebody say Refactoring??? Whoo Hoo!!! Now to the point of providing contributions to a refactoring. The problem with the community doing a refactoring is that some committers and projects start to fear adopter breakage. When you refactor to the point where you start decoupling, that could potentially change interfaces and API. Personally, I think a little adopter breakage is fine as long as there is good reason for it and benefit.

Refactoring for maintainability and readability of the code as well as overall size reduction is usually a good thing.

David Carver

Did somebody say Refactoring??? Whoo Hoo!!! Now to the point of providing contributions to a refactoring. The problem with the community doing a refactoring is that some committers and projects start to fear adopter breakage. When you refactor to the point where you start decoupling, that could potentially change interfaces and API. Personally, I think a little adopter breakage is fine as long as there is good reason for it and benefit.Refactoring for maintainability and readability of the code as well as overall size reduction is usually a good thing.

Chris Aniszczyk (zx)

You can still refactor and not break adopters. For example, all the UA code in PDE was internal… however, the editors associated with each UA thing… has an id… you can refactor this into another plug-in and still use the same id.

For example, the editor id of the TOC editor is ‘org.eclipse.pde.ui.tocEditor’ I plan on keeping that even though it will live in a new bundle (org.eclipse.pde.ua.ui)

Chris Aniszczyk (zx)

You can still refactor and not break adopters. For example, all the UA code in PDE was internal… however, the editors associated with each UA thing… has an id… you can refactor this into another plug-in and still use the same id.For example, the editor id of the TOC editor is ‘org.eclipse.pde.ui.tocEditor’ I plan on keeping that even though it will live in a new bundle (org.eclipse.pde.ua.ui)

David Carver

Agreed…it’s when adopters are using internal API that it becomes sticky. But to me, that is their own fault if they are using something that isn’t official API. Sometimes it’s unavoidable though.

David Carver

Agreed…it’s when adopters are using internal API that it becomes sticky. But to me, that is their own fault if they are using something that isn’t official API. Sometimes it’s unavoidable though.