But please take in account the number of third-party component libraries, which will take time to migrate (if they do ever migrate), and the burden of maintaining two versions of internal libraries (many production systems just won't migrate). I mean, this is not a real need. It's a massive renaming and refactoring whose only purpose is to satisfy the aesthetic sense of some. But it will touch almost each and every class that uses and extends Wicket classes (IModel is pretty pervasive in any Wicket application).
I knew that Wicket developers weren't afraid of breaking backwards compatibility, but I thought it would require a good reason. Oh, my vote earlier is non-binding :) Tetsuo On Sat, Oct 3, 2009 at 6:58 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > i would like to invalidate some of the "migration will be too hard" > concerns with a simple test. you are welcome to run this on your own > projects, i am running it on a midsized project i am working on... > > igor.vaynb...@bender:~/dev/src/biggie$ find -name "*.java" | xargs cat | > wc -l > 192625 > > igor.vaynb...@bender:~/dev/src/biggie$ find -name "*.java" | xargs cat > | grep 'import org\.apache\.wicket[.A-Za-z0-9]*\.I' | dos2unix | sort > | uniq -c > 1 import org.apache.wicket.authorization.IAuthorizationStrategy; > 2 import org.apache.wicket.Component.IVisitor; > 10 import > org.apache.wicket.extensions.markup.html.repeater.data.grid.ICellPopulator; > 31 import org.apache.wicket.extensions.markup.html.tabs.ITab; > 1 import org.apache.wicket.IClusterable; > 2 import org.apache.wicket.IComponentBorder; > 1 import org.apache.wicket.IConverterLocator; > 2 import org.apache.wicket.IRequestTarget; > 29 import org.apache.wicket.markup.html.form.IChoiceRenderer; > 1 import org.apache.wicket.markup.html.form.IFormSubmittingComponent; > 1 import org.apache.wicket.markup.html.form.IFormVisitorParticipant; > 2 import org.apache.wicket.markup.html.form.validation.IFormValidator; > 4 import org.apache.wicket.markup.html.IHeaderContributor; > 6 import org.apache.wicket.markup.html.IHeaderResponse; > 3 import org.apache.wicket.markup.html.image.Image; > 3 import org.apache.wicket.markup.html.link.IPageLink; > 5 import org.apache.wicket.markup.IMarkupResourceStreamProvider; > 4 import org.apache.wicket.markup.repeater.data.IDataProvider; > 39 import org.apache.wicket.markup.repeater.Item; > 3 import org.apache.wicket.model.IDetachable; > 655 import org.apache.wicket.model.IModel; > 1 import org.apache.wicket.request.IRequestCycleProcessor; > 1 import > org.apache.wicket.request.target.coding.IndexedParamUrlCodingStrategy; > 1 import org.apache.wicket.settings.IExceptionSettings; > 2 import org.apache.wicket.util.convert.IConverter; > 5 import org.apache.wicket.util.resource.IResourceStream; > 25 import org.apache.wicket.validation.IValidatable; > 28 import org.apache.wicket.validation.IValidationError; > 27 import org.apache.wicket.validation.IValidator; > > removing the noise we get > > 31 import org.apache.wicket.extensions.markup.html.tabs.ITab; > 29 import org.apache.wicket.markup.html.form.IChoiceRenderer; > 39 import org.apache.wicket.markup.repeater.Item; > 655 import org.apache.wicket.model.IModel; > 25 import org.apache.wicket.validation.IValidatable; > 28 import org.apache.wicket.validation.IValidationError; > 27 import org.apache.wicket.validation.IValidator; > > really the only glaring usage is IModel, but even with the others - > the project can be easily migrated with a sed script - which we may > even provide. > > -igor > > On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: > > is it perhaps time to take the I out of our interface names? wicket > > has been the only project i have ever worked on/used that follows this > > convention, is it time for a change? > > > > this is not meant as a flamewar about which convention is teh > > aw3s0m3st, simply a discussion of whether or not we should switch. > > > > -igor > > >
