Ronald, I think you've missed parts of the discussion ...
I don't agree that using I* and *Impl is not just a matter of taste - but I* is nowhere near as bad as *Impl. And good, consistent naming of classes and other identifiers is a non-trivial aspect of good design and coding, especially in publicly used parts of frameworks with which application developers may feel obliged to stay "consistent". But as I said, this is a pretty long story and we may best agree to disagree if you do not feel the same way. Either way, I did check that there are very few uses of *Impl and noted that already. And what is it you think will break the API on every release? I did not get a sense of anything quite so dramatic. In fact the move from 1.2 to 1.3 and from 1.3 to 1.4 is about as painless as Java permits, and most people are quoting migration times in minutes or hours, not days and weeks. My understanding from the original posts on this thread is that the technique described to incrementally get rid of I* interfaces by deprecating and eventually removing "offending" I* interfaces is exactly the right way to make such an improvement with minimal disruption. Such naming issues may well not be the most most urgent thing to address, agreed, but looking at the bigger picture, you cannot leave unpopular bits of code, implementation/API as is forever just so you don't break inter release compatibility otherwise you'll eventually end up with a ball of mud that is also increasingly fragile. Improvement always comes at a cost, and you have to make a judgement call - we're lucky that the core developers here are well qualified and skilled to make that call. Having spoken briefly to Matej already about some of the changes coming in 1.5, I feel the improvements sound really well thought out, made for the right reasons and well worth making, especially as minimising the pain to the application developer is obviously a key objective for all involved. Regards - Cemal jWeekend OO & Java Technologies, Wicket Training and Development http://jWeekend.com ronaldtm wrote: > >> I agree, names like IThing and ThingImpl can be a sign of not thinking >> too >> hard about naming things (and even a rush to get coding without enough >> thought put into design - but that's a long story). > > I* is just a convention, which some like, others dislike, and *Impl are > perfectly fine when used in private inner classes (the only case I've > found > in a quick search of Wicket's code). > > Good naming is nice, but is not the ultimate goal of good design, for > god's > sake! Backward compatibility (a pragmatic one, not a religious one like > Java's) is much higher in my priorities. > > >> For me, dropping those >> "I" prefixes and any "Impl" suffixes will make the project code-base >> look >> even more credible. > > ... and breaking everything every release will make the project less > credible. > > Will you rename PropertyModel to PropertyLocator? ListModel to > ListLocator? > BreadCrumbModel to BreadCrumbLocator? For the sake of consistency, of > course > :) > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25757036.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
