-1 While I don't like the I-prefix, I don't want to remove it from our interfaces.
I don't see any benefit other than removing some perceived confusion. No matter how you name IModel, the concept will still be confusing as hell. I'm -1 on this proposal because the benefits (which are low, or even non-existant) really don't outweigh the costs for the community: - all documentation (presentations, books, articles, blog entries, tweets, wikis) referencing anything that starts with an I (IDetachable, IClusterable, IModel, IDataProvider, ...) will be obsolete. Unless those proposing this change also invest into fixing all this documentation, this is a deal breaker - all 3rd party components, in presentations, articles, wicket stuff, google code, github, etc will be broken (terracotta, etc.) - Renaming IModel to the already existing and widely used name Model is a recipe for disaster. - there is no pressing need to do this in just one release I might be able to live with a much longer migration path where we *deprecate* Model in favor of ObjectModel for a full major release. So no removing of Model in 1.5, but having it deprecated in 1.5 only to remove it in 1.6 or even 1.7. IModel can then be deprecated in 1.7 in favor of Model[Locator|Proxy|Bikeshed] to be removed at a later time. Martijn On Sat, Oct 3, 2009 at 12:28 AM, 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 > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
