Twitter github

‘Tis the Season to Refactor

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:

[207704] – Decouple org.eclipse.compare from UI

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.

Thank you Compare team for making this happen!

[241145] – [refactoring] move UA code into separate plug-ins

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.

  • 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.

  • 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.