> > What if I have > a class for the iPlayer (a BBC service for watching already broadcast TV > programs online). If I call my class IPlayer do I need to worry that half > the world is going to think it's an interface.
Oh, Apple will have a lot of trouble if they try to use Wicket :) > Again, having such a naming convention in the code is certainly not the end > of the world Exactly! > but to my mind it's a convention that does more harm than good > But how does this harm compare to the harm caused by the cure? You only take Chemotherapy when you die otherwise. I think you guys are underestimating the cost of renaming such central part of the framework. Do whatever you want with *Impl, because it just doesn't occur in public classes. Abstract* and Default* are useful, if they have a consistent meaning. For example, I'm not sure, but I think Default* are ready-to-use complex components, with all style needed out-of-the-box. Abstract* are partial implementations of interfaces, what are very useful. If they are not that consistent, and you can think of really better names (StyledDataTable is * not* better than DefaultDataTable), it may be worth renaming. If you only take the 'I' out of interfaces, you'll break every component, tutorial, documentation, and code sample out there, but at least the concept remains intact. If you also rename IModel to Locator, you'll break either the naming consistency (half *Model, half *Locator), or the already established vocabulary of the framework (if everything changes to *Locator), which is, by far, the worst option. But I still think that both changes are completely unnecessary, and a fruit of pure purism. And it's not a question of skill. In fact, this kind of purism manifests precisely in very skilled developers. I also do this sometimes, but fortunately I always have someone who pulls me back to Earth. And about 'breaking compatibility each release', well, it does happen, and if comes without a very good reason, it becomes harder and harder to sell Wicket to my employee :)
