-1 for renaming I don't see how Name/NameImpl is better than IName/Name. But if you decide to eliminate the prefix "I" please follow the beforementioned suggestion - derive well-named interfaces from the legacy ones and deprecate the latter in 1.6 (!).
I believe the name "Locator" would be nothing better than IModel. >From my perspective IModel solves the following task: 1. Holds the typed value 2. Defers the evaluation of the value (hence the "Locator"?) 3. Supports the lifecycle via detach method. 4. Chains one value with another So it is essentially a value evaluation and lifecycle model. Too many words. I don't like "Object" since this word is too overloaded. Everything is object and therefore "object" can be omitted. I would suggest the name "Value". It is simple, understandable and expectable by the newcomers because component should have its value. Ben Tilford wrote: > > Couldn't you mark IModel as deprecated for 1.5, extend IModel with no > added > api for the Locator, make all implementations use the Locator interface > then > in 1.next remove IModel and define the API in Locator? Or is this really > more than a name change? > > On Mon, Oct 5, 2009 at 9:17 AM, nino martinez wael < > nino.martinez.w...@gmail.com> wrote: > >> -1 (non binding) >> >> argument : What Martijn says :) And we don't use the I prefix at work, >> instead we use Abstract and impl, which sucks too. Im not happy with >> either >> conventions. So until I am aware of one which are perfect, im happy with >> it >> as it are, plus it'll cost less for the community. As Martijn says we >> could >> deprecate it over time making it easier to migrate. >> >> >> -Nino >> >> 2009/10/5 Martijn Dashorst <martijn.dasho...@gmail.com> >> >> > -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 >> > >> > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25771902.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
