There's no need to break the interface. You can simply extend it (i.e. keep the old method name, or even module). The old method name can redirect to the new one. You can add docs and even warn about the old one being deprecated. How much of an issue this is depends on exactly how public your interface is. If it's in a class in your code base that you know is used no where else, and maybe is only called once or twice, then you don't have to worry. If, at the other extreme, it's a CPAN module, then you have to be a lot more careful, and maybe even never remove the old name.
Still, the effort is worth it to me. I try to think of someone coming at my code (from either a user or a maintainer point of view) completely fresh, knowing next to nothing about the code. They'll find it a lot easier to understand if things are named consistently and appropriately. I'm not suggesting renaming things on a whim, or making a change that's *slightly* better (except during early development as you suggest), but sometimes a method has changed subtley over time, to the point where it's doing something completely different to what it's name suggests. Or sometimes the original name was just plain wrong.
Unfortunately, I don't have time right now to list some examples, but I do have some that I may add at a later date :)
In reply to Re^3: Naming of modules that are mean to be inherited only?
by Mutant
in thread Naming of modules that are mean to be inherited only?
by leocharre
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |