if this happened it would only be done to 1.5 which has api breaks anyways - so production systems would not be migrating to 1.5 anyways.
-igor On Sat, Oct 3, 2009 at 4:45 PM, tetsuo <ronald.tet...@gmail.com> wrote: > 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 >> > >> >
