Re: taking the I out of Interface
+1 Beware of lazyness driven crud buildup; although I have always had distate for '*I*Model'... On Wed, Oct 7, 2009 at 1:46 AM, Johan Compagner wrote: > I am 0 but leaning towards -1 because i really dont like renaming > IModel to Model, because that would cause many weird things/compile > problems in my project, and i think thats would be the same for > others. > > Besides that i agree with martijn that then all the books and > documentations are 1 one blow depricated.. > > But if there are really many people for the change i wil not veto it > or something. I only do think it brings more trouble then it fixes. > > On 06/10/2009, Jeremy Thomerson wrote: > > So, I've tried to do a tally of the informal votes (since this was a > > discussion thread). There ended up being a lot of noise on the thread, > so I > > may not have got every vote since some were throwing votes in for > renaming > > model, etc. Anyway, here's what we came up with: > > > > FOR (2 binding / approximately 9 non-binding): > > Matej Knopp > > Igor Vaynberg > > > > > > AGAINST (3 binding / approximately 9 non-binding): > > Martijn Dashorst > > Jeremy Thomerson > > Eelco Hillenius > > > > NO VOTE: > > Johan Compagner(commented on thread, but I wasn't sure what vote > was > > - I think he was voting on model thing) > > UpayaviraAlex KarasuluAte DoumaGwyn EvansJonathan > > LockeJuergen DonnerstagJanne HietamäkiFrank Bille Jensen > Al > > MawJean-Baptiste QuenotGerolf SeitzTimo Rantalaiho > > > > So, can we please all go use our time to look at the *much more > important* > > URL refactoring? Or do we want to continue discussing a divided subject? > > > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > -- Rodolfo Hansen CTO, KindleIT Software Development Email: rhan...@kindleit.net Office: 1 (809) 732-5200 Mobile: 1 (809) 299-7332
Re: taking the I out of Interface
I am 0 but leaning towards -1 because i really dont like renaming IModel to Model, because that would cause many weird things/compile problems in my project, and i think thats would be the same for others. Besides that i agree with martijn that then all the books and documentations are 1 one blow depricated.. But if there are really many people for the change i wil not veto it or something. I only do think it brings more trouble then it fixes. On 06/10/2009, Jeremy Thomerson wrote: > So, I've tried to do a tally of the informal votes (since this was a > discussion thread). There ended up being a lot of noise on the thread, so I > may not have got every vote since some were throwing votes in for renaming > model, etc. Anyway, here's what we came up with: > > FOR (2 binding / approximately 9 non-binding): > Matej Knopp > Igor Vaynberg > > > AGAINST (3 binding / approximately 9 non-binding): > Martijn Dashorst > Jeremy Thomerson > Eelco Hillenius > > NO VOTE: > Johan Compagner(commented on thread, but I wasn't sure what vote was > - I think he was voting on model thing) > UpayaviraAlex KarasuluAte DoumaGwyn EvansJonathan > LockeJuergen DonnerstagJanne HietamäkiFrank Bille JensenAl > MawJean-Baptiste QuenotGerolf SeitzTimo Rantalaiho > > So, can we please all go use our time to look at the *much more important* > URL refactoring? Or do we want to continue discussing a divided subject? > > > -- > Jeremy Thomerson > http://www.wickettraining.com >
Re: taking the I out of Interface
Sorry, missed that. I'm definitely not saying that either side won - I'm saying let's move on since it seems split. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Oct 6, 2009 at 11:19 AM, Eelco Hillenius wrote: > > AGAINST (3 binding / approximately 9 non-binding): > >Martijn Dashorst > >Jeremy Thomerson > >Eelco Hillenius > > Like I said, you don't have to count my vote as a binding one. So it's > a draw then. > > Eelco >
Re: taking the I out of Interface
> AGAINST (3 binding / approximately 9 non-binding): > Martijn Dashorst > Jeremy Thomerson > Eelco Hillenius Like I said, you don't have to count my vote as a binding one. So it's a draw then. Eelco
Re: taking the I out of Interface
-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 >> >> > -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 >> >> > 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.
Re: taking the I out of Interface
On Tue, Oct 6, 2009 at 6:05 PM, Jeremy Thomerson wrote: > So, I've tried to do a tally of the informal votes (since this was a > discussion thread). There ended up being a lot of noise on the thread, so I > may not have got every vote since some were throwing votes in for renaming > model, etc. Anyway, here's what we came up with: > > FOR (2 binding / approximately 9 non-binding): > Matej Knopp > Igor Vaynberg > > > AGAINST (3 binding / approximately 9 non-binding): > Martijn Dashorst > Jeremy Thomerson > Eelco Hillenius > > NO VOTE: > Johan Compagner (commented on thread, but I wasn't sure what vote was > - I think he was voting on model thing) > Upayavira Alex Karasulu Ate Douma Gwyn Evans Jonathan > Locke Juergen Donnerstag Janne Hietamäki Frank Bille Jensen Al > Maw Jean-Baptiste Quenot Gerolf Seitz Timo Rantalaiho > > So, can we please all go use our time to look at the *much more important* > URL refactoring? Or do we want to continue discussing a divided subject? > I don't really think removing I is going to happen so perhaps we can stop beating the dead horse. -Matej
Re: taking the I out of Interface
So, I've tried to do a tally of the informal votes (since this was a discussion thread). There ended up being a lot of noise on the thread, so I may not have got every vote since some were throwing votes in for renaming model, etc. Anyway, here's what we came up with: FOR (2 binding / approximately 9 non-binding): Matej Knopp Igor Vaynberg AGAINST (3 binding / approximately 9 non-binding): Martijn Dashorst Jeremy Thomerson Eelco Hillenius NO VOTE: Johan Compagner(commented on thread, but I wasn't sure what vote was - I think he was voting on model thing) UpayaviraAlex KarasuluAte DoumaGwyn EvansJonathan LockeJuergen DonnerstagJanne HietamäkiFrank Bille JensenAl MawJean-Baptiste QuenotGerolf SeitzTimo Rantalaiho So, can we please all go use our time to look at the *much more important* URL refactoring? Or do we want to continue discussing a divided subject? -- Jeremy Thomerson http://www.wickettraining.com
Re: taking the I out of Interface
> > > > What if I have > > a class for the iPlayer (a BBC service for watching already broadcast TV > > programs online). If I call my class IPlayer do I need to worry that half > > the world is going to think it's an interface. > > > Oh, Apple will have a lot of trouble if they try to use Wicket :) > > > Ahh i wasnt really against it! (Exception introducing Model as in interface what was a Class before that s really not done in my eyes) But now you made my decision easy! If we can block apple or give apple any trouble i vote for keeping that in!!
Re: taking the I out of Interface
+100 On Mon, Oct 5, 2009 at 22:28, Matej Knopp wrote: > Well, some of us think that brace on new lines make the code much > easier to read. > > -Matej > > On Mon, Oct 5, 2009 at 10:25 PM, dtoffe wrote: > > > >Ok, but changing curly braces' alignment would break no compatibility > at > > all... ;-) > > > > Daniel > > > > > > > > jthomerson wrote: > >> > >> Me either - a waste of vertical space. Oh well. > >> > >> -- > >> Jeremy Thomerson > >> http://www.wickettraining.com > >> > >> > >> On Mon, Oct 5, 2009 at 11:56 AM, Eelco Hillenius > >> wrote: > >> > >>> > On Mon, Oct 5, 2009 at 12:14 AM, > >>> > >>> Ah yes, it slowly comes back to me... another case of where I let the > >>> team's preferences override my own. I've *never* preferred the curly > >>> brace on the next line. > >>> > >>> Eelco > >>> > >> > >> > > > > -- > > View this message in context: > http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25756998.html > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > > > > >
Re: taking the I out of Interface
Ronald, It's a strong argument you put forward and you highlight very good issues to back it up that are all practical, intuitive and well backed up points. I repeat, and expect that everyone probably agrees, that it's not the end of the world if the I prefix stays, but the vote is whether it should be taken away (on this release, presumably, which is a pretty major overhaul, albeit mainly internally if not exclusively), and I think it would be the right time to do this sort of refactoring if it's ever going to be done at all. So I'll reiterate the +1 due to all the reasons I have already given - and no, I'm not trying to vote twice! I said it's a long story in my initial post, as I've heard all the arguments both ways so many times from many developers, and there's probably more to come. The sentiment I sense is that some of the core-developers will feel even better about the code-base if they can apply some refactoring, at this most opportune moment, that will reduce, if not eliminate, some of the sub-optimal code/design that inevitably builds up over so many years of rapid coding and applying patches by so many developers, sometimes working slightly independently to fix a problem or add a feature that is critical for their own projects, in a way that may not be the "purest" or most elegant, but is certainly good a enough solution to scratch their particular itch (that others probably want to scratch too), and the tests pass, so it gets included. If the vote goes the other way, then that "convention" should be used absolutely consistently everywhere in the Wicket code base, despite some core developers' stated dislike for it - I don't expect too many application developers will want to use Wicket any less for this, as long as it doesn't put off any core developers. Regards - Cemal jWeekend OO & Java Technologies, Wicket Training and Development http://jWeekend.com ronaldtm wrote: > >> >> What if I have >> a class for the iPlayer (a BBC service for watching already broadcast TV >> programs online). If I call my class IPlayer do I need to worry that half >> the world is going to think it's an interface. > > > Oh, Apple will have a lot of trouble if they try to use Wicket :) > > > >> Again, having such a naming convention in the code is certainly not the >> end >> of the world > > > Exactly! > > > >> but to my mind it's a convention that does more harm than good >> > > But how does this harm compare to the harm caused by the cure? You only > take > Chemotherapy when you die otherwise. > > I think you guys are underestimating the cost of renaming such central > part > of the framework. > > Do whatever you want with *Impl, because it just doesn't occur in public > classes. > > Abstract* and Default* are useful, if they have a consistent meaning. For > example, I'm not sure, but I think Default* are ready-to-use complex > components, with all style needed out-of-the-box. Abstract* are partial > implementations of interfaces, what are very useful. If they are not that > consistent, and you can think of really better names (StyledDataTable is * > not* better than DefaultDataTable), it may be worth renaming. > > If you only take the 'I' out of interfaces, you'll break every component, > tutorial, documentation, and code sample out there, but at least the > concept > remains intact. > > If you also rename IModel to Locator, you'll break either the naming > consistency (half *Model, half *Locator), or the already established > vocabulary of the framework (if everything changes to *Locator), which is, > by far, the worst option. > > But I still think that both changes are completely unnecessary, and a > fruit > of pure purism. And it's not a question of skill. In fact, this kind of > purism manifests precisely in very skilled developers. I also do this > sometimes, but fortunately I always have someone who pulls me back to > Earth. > > And about 'breaking compatibility each release', well, it does happen, and > if comes without a very good reason, it becomes harder and harder to sell > Wicket to my employee :) > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25766649.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
RE: taking the I out of Interface
Hi folks, -1 on removal of I for minor releases. If there really is a need to change this, then it should be done in a major version since it is a very intrusive change. Maybe 2.0 is a good candidate for that. Furthermore I disagree with changing Model into Locator. The term 'model' is very clear to many people. Especially for those using/knowing the MVC pattern. The term 'locator' is not that clear and will increase the learning curve. What is it locating to? The model? In that case it should be named ModelLocator. For purists this might be a better name, but in my opinion it doesn't add much. Regards, Minto van der Sluis -Oorspronkelijk bericht- Van: Girts Ziemelis [mailto:girts.zieme...@gmail.com] Verzonden: dinsdag 6 oktober 2009 11:08 Aan: dev@wicket.apache.org Onderwerp: Re: taking the I out of Interface +1 on removal of I Mostly because names and consistency are very important, not because I dislike I*. I also do not like Model (Locator is much better), but I understand the difficulties in this change - I think it would be even more confusing, when everything currently is related to "models" - wiki, docs, books :( But really, I think this should really be decided between the wicket commiters :). If this will make them love Wicket project even more (at put more hours in it :D ) - they can rename anything they want, I am willing to take whatever steps are required from my part to fix my existing code. Renaming staff is not that hard in modern ide. And so far upgrades from Wicket versions are S easy ... -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25765194. html Sent from the Wicket - Dev mailing list archive at Nabble.com. =DISCLAIMER De informatie in deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Indien u niet de geadresseerde bent, wordt u er hierbij op gewezen, dat u geen recht heeft kennis te nemen van de rest van deze e-mail, deze te gebruiken, te kopieren of te verstrekken aan andere personen dan de geadresseerde. Indien u deze e-mail abusievelijk hebt ontvangen, brengt u dan alstublieft de afzender op de hoogte, waarbij u bij deze gevraagd wordt het originele bericht te vernietigen. Politie Amsterdam-Amstelland is niet verantwoordelijk voor de inhoud van deze e-mail en wijst iedere aansprakelijkheid af voor en/of in verband met alle gevolgen en/of schade van een onjuiste of onvolledige verzending ervan. Tenzij uitdrukkelijk het tegendeel blijkt, kunnen aan dit bericht geen rechten worden ontleend. Het gebruik van Internet e-mail brengt zekere risico?s met zich mee. Daarom wordt iedere aansprakelijkheid voor het gebruik van dit medium door de Politie Amsterdam-Amstelland van de hand gewezen.
Re: taking the I out of Interface
+1 on removal of I Mostly because names and consistency are very important, not because I dislike I*. I also do not like Model (Locator is much better), but I understand the difficulties in this change - I think it would be even more confusing, when everything currently is related to "models" - wiki, docs, books :( But really, I think this should really be decided between the wicket commiters :). If this will make them love Wicket project even more (at put more hours in it :D ) - they can rename anything they want, I am willing to take whatever steps are required from my part to fix my existing code. Renaming staff is not that hard in modern ide. And so far upgrades from Wicket versions are S easy ... -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25765194.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: taking the I out of Interface
> > What if I have > a class for the iPlayer (a BBC service for watching already broadcast TV > programs online). If I call my class IPlayer do I need to worry that half > the world is going to think it's an interface. Oh, Apple will have a lot of trouble if they try to use Wicket :) > Again, having such a naming convention in the code is certainly not the end > of the world Exactly! > but to my mind it's a convention that does more harm than good > But how does this harm compare to the harm caused by the cure? You only take Chemotherapy when you die otherwise. I think you guys are underestimating the cost of renaming such central part of the framework. Do whatever you want with *Impl, because it just doesn't occur in public classes. Abstract* and Default* are useful, if they have a consistent meaning. For example, I'm not sure, but I think Default* are ready-to-use complex components, with all style needed out-of-the-box. Abstract* are partial implementations of interfaces, what are very useful. If they are not that consistent, and you can think of really better names (StyledDataTable is * not* better than DefaultDataTable), it may be worth renaming. If you only take the 'I' out of interfaces, you'll break every component, tutorial, documentation, and code sample out there, but at least the concept remains intact. If you also rename IModel to Locator, you'll break either the naming consistency (half *Model, half *Locator), or the already established vocabulary of the framework (if everything changes to *Locator), which is, by far, the worst option. But I still think that both changes are completely unnecessary, and a fruit of pure purism. And it's not a question of skill. In fact, this kind of purism manifests precisely in very skilled developers. I also do this sometimes, but fortunately I always have someone who pulls me back to Earth. And about 'breaking compatibility each release', well, it does happen, and if comes without a very good reason, it becomes harder and harder to sell Wicket to my employee :)
Re: taking the I out of Interface
Eelco, But that's the whole point - class names that end in Impl are "not a names that communicates what things do well". The point of each implementation is that it is a specialisation of the supertype. So the name should illustrate that - ie HashMap (not a MapImpl). The good news is, this form of ridiculous naming is not a prevalent pattern in the Wicket code base hardly appearing at all, and nowhere public. The reason people argue against the I prefix on interface names is a similar argument but not quite so strong. But still worth making. You should not need such a naming convention to identify something that is clear from the declaration (and the IDE and/or JavaDoc will show you that). What if I have a class for the iPlayer (a BBC service for watching already broadcast TV programs online). If I call my class IPlayer do I need to worry that half the world is going to think it's an interface. I find it extremely illogical to introduce such arbitrary naming conventions with unsound justifications that don't stand up to logical argument and just feel wrong anyway. Here's a discussion on this if anyone is still awake http://www.bigroom.co.uk/blog/the-i-in-interface . Again, having such a naming convention in the code is certainly not the end of the world, but to my mind it's a convention that does more harm than good (and don't get me started on Java(Beans) "getters" and "setters"!). Regards - Cemal jWeekend OO & Java Technologies, Wicket Training and Development http://jWeekend.com Eelco Hillenius wrote: > >> 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 > > True, but imho that has more to do with choosing names that > communicate what things do well, not so much whether there are certain > prefixes or postfxes. > >> 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. > > There's one thing I hate more than making unnecessary API breaks, and > that is accompanying them with annoying deprecation warnings :-) > > Eelco > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25762172.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: taking the I out of Interface
> 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 True, but imho that has more to do with choosing names that communicate what things do well, not so much whether there are certain prefixes or postfxes. > 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. There's one thing I hate more than making unnecessary API breaks, and that is accompanying them with annoying deprecation warnings :-) Eelco
Re: taking the I out of Interface
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.
Re: taking the I out of Interface
Well, some of us think that brace on new lines make the code much easier to read. -Matej On Mon, Oct 5, 2009 at 10:25 PM, dtoffe wrote: > > Ok, but changing curly braces' alignment would break no compatibility at > all... ;-) > > Daniel > > > > jthomerson wrote: >> >> Me either - a waste of vertical space. Oh well. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> On Mon, Oct 5, 2009 at 11:56 AM, Eelco Hillenius >> wrote: >> >>> > On Mon, Oct 5, 2009 at 12:14 AM, >>> >>> Ah yes, it slowly comes back to me... another case of where I let the >>> team's preferences override my own. I've *never* preferred the curly >>> brace on the next line. >>> >>> Eelco >>> >> >> > > -- > View this message in context: > http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25756998.html > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
Re: taking the I out of Interface
Ok, but changing curly braces' alignment would break no compatibility at all... ;-) Daniel jthomerson wrote: > > Me either - a waste of vertical space. Oh well. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > On Mon, Oct 5, 2009 at 11:56 AM, Eelco Hillenius > wrote: > >> > On Mon, Oct 5, 2009 at 12:14 AM, >> >> Ah yes, it slowly comes back to me... another case of where I let the >> team's preferences override my own. I've *never* preferred the curly >> brace on the next line. >> >> Eelco >> > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25756998.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: taking the I out of Interface
> 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 :)
Re: taking the I out of Interface
Mythbusters has proved that a lead balloon can rise. http://www.youtube.com/watch?v=HZSkM-QEeUg Ryan Gravener http://bit.ly/no_word_docs On Mon, Oct 5, 2009 at 1:06 PM, jWeekend wrote: > > +1 > 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). For me, dropping those > "I" prefixes and any "Impl" suffixes will make the project code-base look > even more credible. I don't think we have too many ...Impl's at all (and > that's by far the most offensive of these 2 naming anti-patterns). > The way to you suggest introducing this improvement to the is my preferred, > gentle and step by step, technique too for such a project. > > Regards - Cemal > jWeekend > OO & Java Technologies, Wicket Training and Development > http://jWeekend.com > > PS How about - avoid starting new lines with braces where not absolutely > necessary, too? it's OK, I know this will go down like a lead balloon :-) > > > > > > igor.vaynberg wrote: >> >> we dont do these annoying refactors for no reason. we do not like >> something about the code and want to fix it. >> >> as far as migration pains we can ease that. >> >> take IRequestCycleProcessor as an example. >> >> we can create >> >> interface RequestCycleProcessor extends IRequestCycleProcessor and >> deprecate IRequestCycleProcessor. >> >> release this as 1.5.0.migration jar and then release 1.5.0 with >> IRequestCycleProcessor removed. this gives you as much time as you >> want to migrate your code. >> >> -igor >> >> On Fri, Oct 2, 2009 at 4:14 PM, tetsuo wrote: >>> -1 >>> >>> It breaks compatibility for absolutely no reason. >>> >>> >>> >>> On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: >>> +1 On Oct 2, 2009, at 17:28, Igor Vaynberg 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 > >>> >> >> > > -- > View this message in context: > http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25754608.html > Sent from the Wicket - Dev mailing list archive at Nabble.com. > >
Re: taking the I out of Interface
+1 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). For me, dropping those "I" prefixes and any "Impl" suffixes will make the project code-base look even more credible. I don't think we have too many ...Impl's at all (and that's by far the most offensive of these 2 naming anti-patterns). The way to you suggest introducing this improvement to the is my preferred, gentle and step by step, technique too for such a project. Regards - Cemal jWeekend OO & Java Technologies, Wicket Training and Development http://jWeekend.com PS How about - avoid starting new lines with braces where not absolutely necessary, too? it's OK, I know this will go down like a lead balloon :-) igor.vaynberg wrote: > > we dont do these annoying refactors for no reason. we do not like > something about the code and want to fix it. > > as far as migration pains we can ease that. > > take IRequestCycleProcessor as an example. > > we can create > > interface RequestCycleProcessor extends IRequestCycleProcessor and > deprecate IRequestCycleProcessor. > > release this as 1.5.0.migration jar and then release 1.5.0 with > IRequestCycleProcessor removed. this gives you as much time as you > want to migrate your code. > > -igor > > On Fri, Oct 2, 2009 at 4:14 PM, tetsuo wrote: >> -1 >> >> It breaks compatibility for absolutely no reason. >> >> >> >> On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: >> >>> +1 >>> >>> >>> On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >>> >> > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25754608.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: taking the I out of Interface
Me either - a waste of vertical space. Oh well. -- Jeremy Thomerson http://www.wickettraining.com On Mon, Oct 5, 2009 at 11:56 AM, Eelco Hillenius wrote: > > On Mon, Oct 5, 2009 at 12:14 AM, Eelco Hillenius > > wrote: > >> I never liked the code format we're using (curly braces on the > >> next line), but heck even though Wicket is the only project I've ever > >> worked on (as far as I can remember) where I used that > > > > It's in the Topicus code conventions, so you've been programming (and > > AFAIR advocating) the curly brace on the next line ;-) > > Ah yes, it slowly comes back to me... another case of where I let the > team's preferences override my own. I've *never* preferred the curly > brace on the next line. > > Eelco >
Re: taking the I out of Interface
> On Mon, Oct 5, 2009 at 12:14 AM, Eelco Hillenius > wrote: >> I never liked the code format we're using (curly braces on the >> next line), but heck even though Wicket is the only project I've ever >> worked on (as far as I can remember) where I used that > > It's in the Topicus code conventions, so you've been programming (and > AFAIR advocating) the curly brace on the next line ;-) Ah yes, it slowly comes back to me... another case of where I let the team's preferences override my own. I've *never* preferred the curly brace on the next line. Eelco
Re: taking the I out of Interface
On Mon, Oct 5, 2009 at 7:44 AM, Robin Sander wrote: > Another question because someone mentioned it in this thread and I asked > this question myself: > why do we need an empty interface for Model? Why can't a mere String or any > serializable POJO be > used as a model? (than this discussion about the name would end also...) > I'm not sure I understand what you're saying. IModel is currently the interface and is not an empty interface. And an instance of IModel is a data proxy / location service - not the actual data itself - which is whay any POJO can not be a model. The POJO is the model object. -- Jeremy Thomerson http://www.wickettraining.com
Re: taking the I out of Interface
hmmm i kind of like it IModel or Model And yes talking about abstract we already do that in places we have AbstractRequestCycleProcessor Or do you want to rename that to RequestCycleProcessor but what is then the interface name? It does break quite a lot of api without really fixing anything.. On Sat, Oct 3, 2009 at 00:28, Igor Vaynberg 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 >
Re: taking the I out of Interface
> > how many presentation, books, articles Wicket will have? user will always > look for fresh documentation... > > Users will look for documentation. And what they will find won't work. This is one of the major problems we had with Seam/JSF. It has tons of documentation, but it is incredibly hard to find what you need. Samples don't work when cut-and-paste'd. When buying books you always have to verify which version they refer to. Again, this will cost too much, and will give us *absolutely nothing*besides aesthetic pleasure. And 'best possible naming' is just an opinion.
Re: taking the I out of Interface
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 > > > -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 > > 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 > > >
Re: taking the I out of Interface
+1 I think that removing I from the interfaces names throw a good sign: "User, Wicket team are releasing the best possible code naming, class design, examples, and anything we think is optimal at that moment without any major fireguard. Feel confident of to using our best." - all documentation (presentations, books, articles, blog entries, tweets, wikis) referencing anything that starts with an I how many presentation, books, articles Wicket will have? user will always look for fresh documentation... On Mon, Oct 5, 2009 at 10: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 > > > -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 > > 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 > > > -- Pedro Henrique Oliveira dos Santos
Re: taking the I out of Interface
-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 > -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 > 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 >
Re: taking the I out of Interface
Though I have no commit access for Wicket I want to chime in on the discussion: I would vote for removing the 'I' because personally I dislike it and consider it a violation of Java code conventions. But what's even more important: ! Please choose one or the other and then stick to it and enforce this rule if possible ! (currently it's simply a mess) So if you follow either side of the rule, you would break compatibility anyway and that's why this (otherwise strong) argument against removing the 'I' does not count in my opinion. Hence it's all about personal taste and common conventions => remove the 'I'. Another question because someone mentioned it in this thread and I asked this question myself: why do we need an empty interface for Model? Why can't a mere String or any serializable POJO be used as a model? (than this discussion about the name would end also...) regards, Robin. On Oct 3, 2009, at 00:28, Igor Vaynberg 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
Re: taking the I out of Interface
-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 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
Re: taking the I out of Interface
On Mon, Oct 5, 2009 at 12:14 AM, Eelco Hillenius wrote: > I never liked the code format we're using (curly braces on the > next line), but heck even though Wicket is the only project I've ever > worked on (as far as I can remember) where I used that It's in the Topicus code conventions, so you've been programming (and AFAIR advocating) the curly brace on the next line ;-) Martijn
Re: taking the I out of Interface
+1 Igor Vaynberg 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
Re: taking the I out of Interface
heh, dont confuse "making such a big deal" with an incredibly low-entry barrier into this thread. posting your opinion here requires nothing more than clicking the send button, and of course having an opinion - which everyone always does. compare the turn out in this thread to the incredibly low turn out in the "[wicket 1.5] url handling refactor preview" which is many orders of magnitude more important but requires someone to actually spend 10-20 minutes looking and understanding some code. -igor On Sun, Oct 4, 2009 at 3:14 PM, Eelco Hillenius wrote: > I just want to get off my chest that it is amazing to me we all make > such a big deal out of that "I" being there. It's been there forever, > and with previous discussions we always concluded to leave it in > there. I never liked the code format we're using (curly braces on the > next line), but heck even though Wicket is the only project I've ever > worked on (as far as I can remember) where I used that, it's not > something to lose sleep over. Same with the I, I like it, but I'd be > fine with any alternative. More problematic to me is that we're going > to break a lot of code - including code printed on dead trees - over > it while there is absolutely no benefit other than a superficial one, > and as you can see from the replies in the thread, it's not even > universally thought of as better. And I think that some are a bit too > quick to trivialize that. Breaks, even little ones are annoying and > imho only justifyable when there's a clear benefit to doing that. But > this is plain nitpicking to me. > > I wouldn't give this a blocking vote, even if I had been more active > in the last year, but I'd like to ask everyone to not take even little > API breaks too lightly. > > Eelco >
Re: taking the I out of Interface
> Calling IModel something like Locator, would give us a chance for > other renamings too. LoadableDetachableModel could be renamed to > LoadingDetachingLocator. -1000. Locator *might* have been a good name for what we now call Model, had it been introduced right from the start, but I doubt even that. I offer two arguments against ever changing this now, though: - A Model is a well-known concept in software engineering, and Wicket's usage matches that of Swing. - Model is an entrenched name by now. Renaming it now would confuse everybody and their dog, including newcomers who read old documentation or existing books. I don't really care one way or another about moving away from the I-convention with interfaces. I don't like it, it's not "standard", but it's at least a pattern that almost everybody has heard of. I don't see any pressing need to move away from it, so I'm maybe -0.1 here :-) If the I is removed and Model needs to be renamed so as not to collide with the ex-IModel, I think ObjectModel or DefaultModel would be suitable names. Carl-Eric
Re: taking the I out of Interface
I just want to get off my chest that it is amazing to me we all make such a big deal out of that "I" being there. It's been there forever, and with previous discussions we always concluded to leave it in there. I never liked the code format we're using (curly braces on the next line), but heck even though Wicket is the only project I've ever worked on (as far as I can remember) where I used that, it's not something to lose sleep over. Same with the I, I like it, but I'd be fine with any alternative. More problematic to me is that we're going to break a lot of code - including code printed on dead trees - over it while there is absolutely no benefit other than a superficial one, and as you can see from the replies in the thread, it's not even universally thought of as better. And I think that some are a bit too quick to trivialize that. Breaks, even little ones are annoying and imho only justifyable when there's a clear benefit to doing that. But this is plain nitpicking to me. I wouldn't give this a blocking vote, even if I had been more active in the last year, but I'd like to ask everyone to not take even little API breaks too lightly. Eelco
Re: taking the I out of Interface
Am 04.10.2009 um 20:33 schrieb Erik van Oosten: Martin Grigorov wrote: @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. See earlier threads about this. Martin did not come with this suggestion out of the blue. well, yes your right its not a statement I'd say I'm the originator of. 'Pro Wicket' comes to that conclusion: http://books.google.de/books?id=bA8yTZIZQCsC&lpg=PA6&ots=mmvCTadLn7&dq=wicket%20model%20misnomer&pg=PA6#v =onepage&q=wicket%20model%20misnomer&f=false also WIA does so on page 41 (sorry no online source for that). Though not being the originator, I very much agree with the statement. Esp. the IModel I find problematic. I myself might have gotten used to it, but I've noticed on the job that this naming is something novice programmers tend to stumble (a little bit) over. Calling IModel something like Locator, would give us a chance for other renamings too. LoadableDetachableModel could be renamed to LoadingDetachingLocator. mf Just a brief summary: in any non-Wicket application the term 'model' refer to objects containing business data, often entities. In Wicket apps these are called model-objects. So, Wicket's models are not really 'model's but a 'proxy', a 'locator' or whatever that hide the 'real' model. So I would explain something like: "Wicket consist of components and locators (and all implementations of locator end with **Locator as they have been renamed too). The locators provide access to your business data, the models." And then I would go: "For those that still work with pre-1.5 this will be hellishly confusing as they were mistakenly called model and model-object before." Jeremy Thomerson wrote: I think he meant rename IModel to Locator. I think that Locator or DataProxy or something more accurately describes it I like DataProxy too. (nobody ever understands IModel right off the bat). But I don't think changing it is worth the costs it would incur. Well, if we can drop the 'I', we could drop IModel as well But you are right, it is a big change /which can only be done if there is a good migration path/. So lets please go to the original subject and forget about this. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: taking the I out of Interface
Martin Grigorov wrote: @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. See earlier threads about this. Martin did not come with this suggestion out of the blue. Just a brief summary: in any non-Wicket application the term 'model' refer to objects containing business data, often entities. In Wicket apps these are called model-objects. So, Wicket's models are not really 'model's but a 'proxy', a 'locator' or whatever that hide the 'real' model. So I would explain something like: "Wicket consist of components and locators (and all implementations of locator end with **Locator as they have been renamed too). The locators provide access to your business data, the models." And then I would go: "For those that still work with pre-1.5 this will be hellishly confusing as they were mistakenly called model and model-object before." Jeremy Thomerson wrote: I think he meant rename IModel to Locator. I think that Locator or DataProxy or something more accurately describes it I like DataProxy too. (nobody ever understands IModel right off the bat). But I don't think changing it is worth the costs it would incur. Well, if we can drop the 'I', we could drop IModel as well But you are right, it is a big change /which can only be done if there is a good migration path/. So lets please go to the original subject and forget about this. Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: taking the I out of Interface
sometimes more concise class names are better... Sure, but so concise that it doesn't differentiates itself from other models? If I see ObjectModel i would assume that it keeps reference to an object. OK, I wouldn't. Sven Matej Knopp wrote: On Sun, Oct 4, 2009 at 6:33 PM, Sven Meier wrote: Hi Matej, I don't know how my suggestion is related to seriousness, you don't have to question my Java 101. I'm not questioning your Java 101. But in your previous email you basically suggested that ObjectModel can't hold a collection because I said it holds single object. I was specifically referring to your statement: ObjectModel sounds like a really good name to me because it says what it does. Holds single object. I thought you wanted to emphasize *single*, which doesn't fit for many cases where Wicket components access a list of objects through their model. I know that a collection object is still a single instance but semantically it's 'many'. BTW we had this discussion about introducing a specialized collection model a few months ago. I didn't emphasize single. I just stated a fact. If i wanted to emphasize single I would have called it SingleObjectModel. Collection in java is an object. If I call something ObjectModel do you have any reason to assume that it can't hold a collection? Every model provides access to an object, so the emphasis can't be on *object* either. Every model provides access to an object but every model does it differently. If I see ObjectModel i would assume that it keeps reference to an object. I could have of course suggested ObjectReferenceKeepingModel but sometimes more concise class names are better... If you want to stress the fact, that the current Model class *holds* an object, then why don't you suggest to rename it to HoldModel? Why would I want to do that? -Matej Regards Sven Matej Knopp wrote: On Sun, Oct 4, 2009 at 5:47 PM, Sven Meier wrote: So ObjectModel will hold a single object only? What about lists and collections? Are you serious? A collection is still one instance. It doesn't matter how many references it holds. -Matej IMHO the "Object.." prefix has no benefit. Why not drop the Model class altogether? Its static helper methods could be located in a new non-instantiable class Models (note the trailing 's') because there's nothing more exciting the Model class currently provides. My 2 cents Sven Matej Knopp wrote: Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: +1 for removing 'I'. I personally do like it but since this is what the committers prefer than I'm fine. -1 for renaming Model to anything else. @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. A side note: some third party projects already depends on 'I' classes. For example Terracotta depends on IClusterable for its Wicket module. Take this into account as well. El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: I agree, the I is useless. Provided there is a good migration I'd say: +1. I also agree with Martin, lets change IModel to Locator while we're at it! Regards, Erik. Igor Vaynberg 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
Re: taking the I out of Interface
On Sun, Oct 4, 2009 at 6:33 PM, Sven Meier wrote: > Hi Matej, > > I don't know how my suggestion is related to seriousness, you don't have to > question my Java 101. I'm not questioning your Java 101. But in your previous email you basically suggested that ObjectModel can't hold a collection because I said it holds single object. > > I was specifically referring to your statement: > >>ObjectModel sounds like a really good name to me because it says what it >> does. >>Holds single object. > > I thought you wanted to emphasize *single*, which doesn't fit for many cases > where Wicket components access a list of objects through their model. I know > that a collection object is still a single instance but semantically it's > 'many'. BTW we had this discussion about introducing a specialized > collection model a few months ago. I didn't emphasize single. I just stated a fact. If i wanted to emphasize single I would have called it SingleObjectModel. Collection in java is an object. If I call something ObjectModel do you have any reason to assume that it can't hold a collection? > > Every model provides access to an object, so the emphasis can't be on > *object* either. Every model provides access to an object but every model does it differently. If I see ObjectModel i would assume that it keeps reference to an object. I could have of course suggested ObjectReferenceKeepingModel but sometimes more concise class names are better... > > If you want to stress the fact, that the current Model class *holds* an > object, then why don't you suggest to rename it to HoldModel? Why would I want to do that? -Matej > > Regards > > Sven > > Matej Knopp wrote: >> >> On Sun, Oct 4, 2009 at 5:47 PM, Sven Meier wrote: >> >>> >>> So ObjectModel will hold a single object only? What about lists and >>> collections? >>> >> >> Are you serious? A collection is still one instance. It doesn't matter >> how many references it holds. >> >> -Matej >> >>> >>> IMHO the "Object.." prefix has no benefit. >>> >>> Why not drop the Model class altogether? >>> Its static helper methods could be located in a new non-instantiable >>> class >>> Models (note the trailing 's') because there's nothing more exciting the >>> Model class currently provides. >>> >>> My 2 cents >>> >>> Sven >>> >>> >>> Matej Knopp wrote: >>> Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: > > +1 for removing 'I'. I personally do like it but since this is what the > committers prefer than I'm fine. > > -1 for renaming Model to anything else. > @Erik: it'd be interesting to be at a course of jWeekend where you'll > explain to the attendees "Wicket consists of components, models, ... > and > the basic model is Locator (and all implementations end with **Model)". > I'll find it confusing. > I hope Wicket 1.5 will not rename all existing Model implementations. > > A side note: some third party projects already depends on 'I' classes. > For example Terracotta depends on IClusterable for its Wicket module. > Take this into account as well. > > El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: > > >> >> I agree, the I is useless. Provided there is a good migration I'd say: >> +1. >> >> I also agree with Martin, lets change IModel to Locator while we're at >> it! >> >> Regards, >> Erik. >> >> >> Igor Vaynberg 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 >>> >>> >>> >> >> > > >>> >>> > >
Re: taking the I out of Interface
ObjectModel to me says that it holds an object. a Person is an object, so is a List or a Set... -igor On Sun, Oct 4, 2009 at 9:33 AM, Sven Meier wrote: > Hi Matej, > > I don't know how my suggestion is related to seriousness, you don't have to > question my Java 101. > > I was specifically referring to your statement: > >>ObjectModel sounds like a really good name to me because it says what it >> does. >>Holds single object. > > I thought you wanted to emphasize *single*, which doesn't fit for many cases > where Wicket components access a list of objects through their model. I know > that a collection object is still a single instance but semantically it's > 'many'. BTW we had this discussion about introducing a specialized > collection model a few months ago. > > Every model provides access to an object, so the emphasis can't be on > *object* either. > > If you want to stress the fact, that the current Model class *holds* an > object, then why don't you suggest to rename it to HoldModel? > > Regards > > Sven > > Matej Knopp wrote: >> >> On Sun, Oct 4, 2009 at 5:47 PM, Sven Meier wrote: >> >>> >>> So ObjectModel will hold a single object only? What about lists and >>> collections? >>> >> >> Are you serious? A collection is still one instance. It doesn't matter >> how many references it holds. >> >> -Matej >> >>> >>> IMHO the "Object.." prefix has no benefit. >>> >>> Why not drop the Model class altogether? >>> Its static helper methods could be located in a new non-instantiable >>> class >>> Models (note the trailing 's') because there's nothing more exciting the >>> Model class currently provides. >>> >>> My 2 cents >>> >>> Sven >>> >>> >>> Matej Knopp wrote: >>> Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: > > +1 for removing 'I'. I personally do like it but since this is what the > committers prefer than I'm fine. > > -1 for renaming Model to anything else. > @Erik: it'd be interesting to be at a course of jWeekend where you'll > explain to the attendees "Wicket consists of components, models, ... > and > the basic model is Locator (and all implementations end with **Model)". > I'll find it confusing. > I hope Wicket 1.5 will not rename all existing Model implementations. > > A side note: some third party projects already depends on 'I' classes. > For example Terracotta depends on IClusterable for its Wicket module. > Take this into account as well. > > El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: > > >> >> I agree, the I is useless. Provided there is a good migration I'd say: >> +1. >> >> I also agree with Martin, lets change IModel to Locator while we're at >> it! >> >> Regards, >> Erik. >> >> >> Igor Vaynberg 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 >>> >>> >>> >> >> > > >>> >>> > >
Re: taking the I out of Interface
Hi Matej, I don't know how my suggestion is related to seriousness, you don't have to question my Java 101. I was specifically referring to your statement: >ObjectModel sounds like a really good name to me because it says what it does. >Holds single object. I thought you wanted to emphasize *single*, which doesn't fit for many cases where Wicket components access a list of objects through their model. I know that a collection object is still a single instance but semantically it's 'many'. BTW we had this discussion about introducing a specialized collection model a few months ago. Every model provides access to an object, so the emphasis can't be on *object* either. If you want to stress the fact, that the current Model class *holds* an object, then why don't you suggest to rename it to HoldModel? Regards Sven Matej Knopp wrote: On Sun, Oct 4, 2009 at 5:47 PM, Sven Meier wrote: So ObjectModel will hold a single object only? What about lists and collections? Are you serious? A collection is still one instance. It doesn't matter how many references it holds. -Matej IMHO the "Object.." prefix has no benefit. Why not drop the Model class altogether? Its static helper methods could be located in a new non-instantiable class Models (note the trailing 's') because there's nothing more exciting the Model class currently provides. My 2 cents Sven Matej Knopp wrote: Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: +1 for removing 'I'. I personally do like it but since this is what the committers prefer than I'm fine. -1 for renaming Model to anything else. @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. A side note: some third party projects already depends on 'I' classes. For example Terracotta depends on IClusterable for its Wicket module. Take this into account as well. El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: I agree, the I is useless. Provided there is a good migration I'd say: +1. I also agree with Martin, lets change IModel to Locator while we're at it! Regards, Erik. Igor Vaynberg 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
Re: taking the I out of Interface
+1 data proxy or model proxy or proxymodel or wrapper model 2009/10/4 Jeremy Thomerson : > On Sun, Oct 4, 2009 at 8:45 AM, Matej Knopp wrote: > >> Should we rename IModel to Model we would also have to rename Model to >> something. ObjectModel sounds like a really good name to me because it >> says what it does. Holds single object. >> >> Locator sounds really weird. I think renaming Model to Locator would >> be hell lot more confusing than renaming IModel to Model. >> > > > I think he meant rename IModel to Locator. I think that Locator or > DataProxy or something more accurately describes it (nobody ever understands > IModel right off the bat). But I don't think changing it is worth the costs > it would incur. > > -- > Jeremy Thomerson > http://www.wickettraining.com >
Re: taking the I out of Interface
why would a locator have a set method? -igor On Sun, Oct 4, 2009 at 4:55 AM, Erik van Oosten wrote: > I agree, the I is useless. Provided there is a good migration I'd say: +1. > > I also agree with Martin, lets change IModel to Locator while we're at it! > > Regards, > Erik. > > > Igor Vaynberg 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 >> > > > -- > Erik van Oosten > http://www.day-to-day-stuff.blogspot.com/ > >
Re: taking the I out of Interface
On Sun, Oct 4, 2009 at 8:45 AM, Matej Knopp wrote: > Should we rename IModel to Model we would also have to rename Model to > something. ObjectModel sounds like a really good name to me because it > says what it does. Holds single object. > > Locator sounds really weird. I think renaming Model to Locator would > be hell lot more confusing than renaming IModel to Model. > I think he meant rename IModel to Locator. I think that Locator or DataProxy or something more accurately describes it (nobody ever understands IModel right off the bat). But I don't think changing it is worth the costs it would incur. -- Jeremy Thomerson http://www.wickettraining.com
Re: taking the I out of Interface
On Sun, Oct 4, 2009 at 5:47 PM, Sven Meier wrote: > So ObjectModel will hold a single object only? What about lists and > collections? Are you serious? A collection is still one instance. It doesn't matter how many references it holds. -Matej > IMHO the "Object.." prefix has no benefit. > > Why not drop the Model class altogether? > Its static helper methods could be located in a new non-instantiable class > Models (note the trailing 's') because there's nothing more exciting the > Model class currently provides. > > My 2 cents > > Sven > > > Matej Knopp wrote: >> >> Should we rename IModel to Model we would also have to rename Model to >> something. ObjectModel sounds like a really good name to me because it >> says what it does. Holds single object. >> >> Locator sounds really weird. I think renaming Model to Locator would >> be hell lot more confusing than renaming IModel to Model. >> >> -Matej >> >> On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov >> wrote: >> >>> >>> +1 for removing 'I'. I personally do like it but since this is what the >>> committers prefer than I'm fine. >>> >>> -1 for renaming Model to anything else. >>> @Erik: it'd be interesting to be at a course of jWeekend where you'll >>> explain to the attendees "Wicket consists of components, models, ... and >>> the basic model is Locator (and all implementations end with **Model)". >>> I'll find it confusing. >>> I hope Wicket 1.5 will not rename all existing Model implementations. >>> >>> A side note: some third party projects already depends on 'I' classes. >>> For example Terracotta depends on IClusterable for its Wicket module. >>> Take this into account as well. >>> >>> El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: >>> I agree, the I is useless. Provided there is a good migration I'd say: +1. I also agree with Martin, lets change IModel to Locator while we're at it! Regards, Erik. Igor Vaynberg 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 > > >>> >>> > >
Re: taking the I out of Interface
So ObjectModel will hold a single object only? What about lists and collections? IMHO the "Object.." prefix has no benefit. Why not drop the Model class altogether? Its static helper methods could be located in a new non-instantiable class Models (note the trailing 's') because there's nothing more exciting the Model class currently provides. My 2 cents Sven Matej Knopp wrote: Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: +1 for removing 'I'. I personally do like it but since this is what the committers prefer than I'm fine. -1 for renaming Model to anything else. @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. A side note: some third party projects already depends on 'I' classes. For example Terracotta depends on IClusterable for its Wicket module. Take this into account as well. El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: I agree, the I is useless. Provided there is a good migration I'd say: +1. I also agree with Martin, lets change IModel to Locator while we're at it! Regards, Erik. Igor Vaynberg 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
Re: taking the I out of Interface
El dom, 04-10-2009 a las 15:45 +0200, Matej Knopp escribió: > Should we rename IModel to Model we would also have to rename Model to > something. ObjectModel sounds like a really good name to me because it > says what it does. Holds single object. > > Locator sounds really weird. I think renaming Model to Locator would > be hell lot more confusing than renaming IModel to Model. Fully agree. > > -Matej > > On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: > > +1 for removing 'I'. I personally do like it but since this is what the > > committers prefer than I'm fine. > > > > -1 for renaming Model to anything else. > > @Erik: it'd be interesting to be at a course of jWeekend where you'll > > explain to the attendees "Wicket consists of components, models, ... and > > the basic model is Locator (and all implementations end with **Model)". > > I'll find it confusing. > > I hope Wicket 1.5 will not rename all existing Model implementations. > > > > A side note: some third party projects already depends on 'I' classes. > > For example Terracotta depends on IClusterable for its Wicket module. > > Take this into account as well. > > > > El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: > >> I agree, the I is useless. Provided there is a good migration I'd say: +1. > >> > >> I also agree with Martin, lets change IModel to Locator while we're at it! > >> > >> Regards, > >> Erik. > >> > >> > >> Igor Vaynberg 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 > >> > > >> > >> > > > > >
Re: taking the I out of Interface
Should we rename IModel to Model we would also have to rename Model to something. ObjectModel sounds like a really good name to me because it says what it does. Holds single object. Locator sounds really weird. I think renaming Model to Locator would be hell lot more confusing than renaming IModel to Model. -Matej On Sun, Oct 4, 2009 at 3:19 PM, Martin Grigorov wrote: > +1 for removing 'I'. I personally do like it but since this is what the > committers prefer than I'm fine. > > -1 for renaming Model to anything else. > @Erik: it'd be interesting to be at a course of jWeekend where you'll > explain to the attendees "Wicket consists of components, models, ... and > the basic model is Locator (and all implementations end with **Model)". > I'll find it confusing. > I hope Wicket 1.5 will not rename all existing Model implementations. > > A side note: some third party projects already depends on 'I' classes. > For example Terracotta depends on IClusterable for its Wicket module. > Take this into account as well. > > El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: >> I agree, the I is useless. Provided there is a good migration I'd say: +1. >> >> I also agree with Martin, lets change IModel to Locator while we're at it! >> >> Regards, >> Erik. >> >> >> Igor Vaynberg 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 >> > >> >> > >
Re: taking the I out of Interface
+1 for removing 'I'. I personally do like it but since this is what the committers prefer than I'm fine. -1 for renaming Model to anything else. @Erik: it'd be interesting to be at a course of jWeekend where you'll explain to the attendees "Wicket consists of components, models, ... and the basic model is Locator (and all implementations end with **Model)". I'll find it confusing. I hope Wicket 1.5 will not rename all existing Model implementations. A side note: some third party projects already depends on 'I' classes. For example Terracotta depends on IClusterable for its Wicket module. Take this into account as well. El dom, 04-10-2009 a las 13:55 +0200, Erik van Oosten escribió: > I agree, the I is useless. Provided there is a good migration I'd say: +1. > > I also agree with Martin, lets change IModel to Locator while we're at it! > > Regards, > Erik. > > > Igor Vaynberg 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 > > > >
Re: taking the I out of Interface
I agree, the I is useless. Provided there is a good migration I'd say: +1. I also agree with Martin, lets change IModel to Locator while we're at it! Regards, Erik. Igor Vaynberg 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 -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: taking the I out of Interface
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 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 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 >> 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 >> > >> >
Re: taking the I out of Interface
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 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 > 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 > > >
Re: taking the I out of Interface
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 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 >
Re: taking the I out of Interface
+1 (non binding), as long as you also remove every *Impl (if there is any) and provide a migration path as you previously sketched (Model extends IModel and deprecating IModel). imho this is a normal step in a project's evolution, you add functionality, the initial design breaks a little, then you do some cleanup (as in url handling refactor), small refactorings like taking out the "I" and so on. You end up with a good design and consistent naming, and then when more functionality is added, it will be easier to do because the code is clean, and the users will also benefit from this. Of course it is not free, but I believe the benefits for devs and users far outweight the cost of minor migrations. Daniel igor.vaynberg 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 > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25728939.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: taking the I out of Interface
I don't think the analogy with tapestry is right. We break stuff between every major release but we also provide migration path. In tapestry the migration path is pretty much non-existent. The problem with tapestry is not that they break stuff. The problem is that you have to rewrite entire application if you want to update. -Matej On Sat, Oct 3, 2009 at 2:37 PM, James Carman wrote: > For the record, I'm -1 also (non-binding of course). We have to be > careful here. Tapestry got a bad reputation for changing things way > too much between major revisions and leaving their users out in the > cold. It's one of the reasons I'm in the "Wicket World" these days. > By no means do I want to stifle innovation or anything, but breaking > compatibility should come with a rather big value-add. In this case, > I agree that the "I" is ugly and I actually hate it, but how much is > it actually going to improve a Wicket user's day-to-day coding with > Wicket. Is it going to save hundreds of lines of code? Is it going > to save 20 minutes of development time per day? > > On Sat, Oct 3, 2009 at 5:02 AM, Matej Knopp wrote: >> Anyhow, this doesn't look like lot of people are in favor of dropping >> I. In that case we should make sure that *all* interfaces in 1.5 are >> prefixed in I. If we go the (imho) ugly and non conventional way then >> we should at least be consistent. >> >> -Matej >> >> On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg >> 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 >>> >> >
Re: taking the I out of Interface
Very good point. I am worried that changing the "i" will only make some very few core develoeprs or newcomers slightly bit happier until they forget about that new thang. ** Martin 2009/10/3 James Carman : > For the record, I'm -1 also (non-binding of course). We have to be > careful here. Tapestry got a bad reputation for changing things way > too much between major revisions and leaving their users out in the > cold. It's one of the reasons I'm in the "Wicket World" these days. > By no means do I want to stifle innovation or anything, but breaking > compatibility should come with a rather big value-add. In this case, > I agree that the "I" is ugly and I actually hate it, but how much is > it actually going to improve a Wicket user's day-to-day coding with > Wicket. Is it going to save hundreds of lines of code? Is it going > to save 20 minutes of development time per day? > > On Sat, Oct 3, 2009 at 5:02 AM, Matej Knopp wrote: >> Anyhow, this doesn't look like lot of people are in favor of dropping >> I. In that case we should make sure that *all* interfaces in 1.5 are >> prefixed in I. If we go the (imho) ugly and non conventional way then >> we should at least be consistent. >> >> -Matej >> >> On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg >> 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 >>> >> >
Re: taking the I out of Interface
For the record, I'm -1 also (non-binding of course). We have to be careful here. Tapestry got a bad reputation for changing things way too much between major revisions and leaving their users out in the cold. It's one of the reasons I'm in the "Wicket World" these days. By no means do I want to stifle innovation or anything, but breaking compatibility should come with a rather big value-add. In this case, I agree that the "I" is ugly and I actually hate it, but how much is it actually going to improve a Wicket user's day-to-day coding with Wicket. Is it going to save hundreds of lines of code? Is it going to save 20 minutes of development time per day? On Sat, Oct 3, 2009 at 5:02 AM, Matej Knopp wrote: > Anyhow, this doesn't look like lot of people are in favor of dropping > I. In that case we should make sure that *all* interfaces in 1.5 are > prefixed in I. If we go the (imho) ugly and non conventional way then > we should at least be consistent. > > -Matej > > On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg > 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 >> >
Re: taking the I out of Interface
Anyhow, this doesn't look like lot of people are in favor of dropping I. In that case we should make sure that *all* interfaces in 1.5 are prefixed in I. If we go the (imho) ugly and non conventional way then we should at least be consistent. -Matej On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg 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 >
Re: taking the I out of Interface
Ok, that's a good answer. If this is true, I will vote for what ever makes the artists happy. ** Martin 2009/10/3 Matej Knopp : > Oh come one. There are like 5 interfaces in Wicket prefixed with I > that projects normally use. Couple of search and replace will > certainly not bankrupt anyone. > > -Matej > > On Sat, Oct 3, 2009 at 10:51 AM, Martin Makundi > wrote: >> I am also curious how much more difficult it will make to switch from >> 1.4 to 1.5. The cost of renaming according to some fasion might >> accumulate to millions of dollars in worldwide development teams. Just >> for the sake of some damn "another naming gimmic" which does not bring >> any real functionality (no value trade off for the money spent). >> >> ** >> Martin >> >
Re: taking the I out of Interface
Oh come one. There are like 5 interfaces in Wicket prefixed with I that projects normally use. Couple of search and replace will certainly not bankrupt anyone. -Matej On Sat, Oct 3, 2009 at 10:51 AM, Martin Makundi wrote: > I am also curious how much more difficult it will make to switch from > 1.4 to 1.5. The cost of renaming according to some fasion might > accumulate to millions of dollars in worldwide development teams. Just > for the sake of some damn "another naming gimmic" which does not bring > any real functionality (no value trade off for the money spent). > > ** > Martin >
Re: taking the I out of Interface
I am also curious how much more difficult it will make to switch from 1.4 to 1.5. The cost of renaming according to some fasion might accumulate to millions of dollars in worldwide development teams. Just for the sake of some damn "another naming gimmic" which does not bring any real functionality (no value trade off for the money spent). ** Martin
Re: taking the I out of Interface
-1 I've got to like the convention after sometime using Wicket. Right now when I want to look for an interface and I do not remember his exact name typing ctr-shit-T and I on eclipse will provide me with an initial list to be further filtered out... But I guess I will get used to other conventions as far as Wicket continues to be such a good framework. Ernesto On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg 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 >
Re: taking the I out of Interface
renaming season? I think Model (interface) / ObjectModel is the best alternative. ObjectModel says enough about the implementation - that it holds a single object. But I don't think this thread is about actual naming. It's more about pros & cons of the prefix. Get rid of IModel, call it Locator. This would allow to give ObjectModel its true name: 'Model' mf
Re: taking the I out of Interface
Well.. if it runs it ain't broken. But ofcourse if we want to refactor just for the sake of arts, why the hell not! ** Martin 2009/10/3 Matej Knopp : >> "If it ain't broken, don't try to fix it." > > The thing here is that not all of us agree that it ain't broken. > > -Matej >
Re: taking the I out of Interface
+1 (non-binding) -- AT®
Re: taking the I out of Interface
> "If it ain't broken, don't try to fix it." The thing here is that not all of us agree that it ain't broken. -Matej
Re: taking the I out of Interface
-1 "If it ain't broken, don't try to fix it." ** Martin
RE: taking the I out of Interface
I don't have a problem with breaking compatibility. Makeing a step forward and making things better always leaves behind something. Mostly something not so good. I like the way wicket names interfaces with I... and we followed this conventiun in our coding rules. But taking a look at some of our wicket projects shows that we use only a few of Wicket's I... directly - IModel (sure) - ITab - IColumn - ILinkListener - IUnauthorizedComponentInstantiationListener That's nearly all. Only very few others and only one occurence per project. Stefan. -Ursprüngliche Nachricht- Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Gesendet: Samstag, 3. Oktober 2009 03:03 An: dev@wicket.apache.org Betreff: Re: taking the I out of Interface for people who are going to say that this is going to break compatibility: please look through your code and count the number of places where you implement a wicket-specific interface directly. we would like to know how often and what these interfaces are. thanks, -igor On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg 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 >
Re: taking the I out of Interface
+1 (non-binding) The 'I' is inconsistent with standard Java libraries (example: there is no IList, IMap, IIterable etc. in java.util) and I suspect many other Java projects. A more minor consideration is that for the small but growing number of people that use Wicket through Scala, where you have 'traits' instead of interfaces and abstract classes. The distinction between interfaces and classes in Scala is even more blurred in the Java language. It probably not a concern of Wicket, but I'll put it out there anyway, for interest's sake if nothing else. -- Sam. On Fri, 02 Oct 2009 15:28:50 -0700, Igor Vaynberg 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
Re: taking the I out of Interface
oh, but we have a lot of Abstract* classes, some of them might even have your name on it :) -igor On Fri, Oct 2, 2009 at 8:02 PM, Eelco Hillenius wrote: > -1 > > Breaks compatibility for nothing other than a superficial > 'improvement'. Also, I do see the I used in other projects, and > actually like the convention (a whole lot better than using > AbstractFoo and Fooimpl fwiw). > > Eelco > > On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg 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 >> >
Re: taking the I out of Interface
Oh, +42 on removing I, and +42 on removing *Impl On Oct 2, 2009, at 9:17 PM, Matej Knopp wrote: I think that IFoo and Foo is every bit as bad as Foo and FooImpl. Both show rather poor choice of naming. Same goes for IModel and Model. -Matej On Sat, Oct 3, 2009 at 5:02 AM, Eelco Hillenius wrote: -1 Breaks compatibility for nothing other than a superficial 'improvement'. Also, I do see the I used in other projects, and actually like the convention (a whole lot better than using AbstractFoo and Fooimpl fwiw). Eelco On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg > 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 Johan Edstrom j...@opennms.org They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: taking the I out of Interface
I think that IFoo and Foo is every bit as bad as Foo and FooImpl. Both show rather poor choice of naming. Same goes for IModel and Model. -Matej On Sat, Oct 3, 2009 at 5:02 AM, Eelco Hillenius wrote: > -1 > > Breaks compatibility for nothing other than a superficial > 'improvement'. Also, I do see the I used in other projects, and > actually like the convention (a whole lot better than using > AbstractFoo and Fooimpl fwiw). > > Eelco > > On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg 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 >> >
Re: taking the I out of Interface
-1 as well. Since the vote seems to be nothing more than "I like it" or "I don't like it" I like it. I use it in my projects as well. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Oct 2, 2009 at 10:02 PM, Eelco Hillenius wrote: > -1 > > Breaks compatibility for nothing other than a superficial > 'improvement'. Also, I do see the I used in other projects, and > actually like the convention (a whole lot better than using > AbstractFoo and Fooimpl fwiw). > > Eelco > > On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg > 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 > > >
Re: taking the I out of Interface
-1 Breaks compatibility for nothing other than a superficial 'improvement'. Also, I do see the I used in other projects, and actually like the convention (a whole lot better than using AbstractFoo and Fooimpl fwiw). Eelco On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg 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 >
Re: taking the I out of Interface
It's not just the models. There are plenty of internal interfaces in wicket that have the I prefix. And it's not even consistent. Some interfaces have it some don't. So every time I'm looking for something not only do I have to know if it is an interface but I also have to know whether it starts with an I, which not all do. As for the naming, IModel/Model is what we have now. Apart from not being very java like the name Model doesn't say much about it's nature. Model/ModelImpl is probably even worse. Everytime I see class that ends with Impl I have to ask myself whether there really was a point in extracting the interface. I think Model (interface) / ObjectModel is the best alternative. ObjectModel says enough about the implementation - that it holds a single object. But I don't think this thread is about actual naming. It's more about pros & cons of the prefix. -Matej On Sat, Oct 3, 2009 at 3:58 AM, Ryan Gravener wrote: > It's just my preference. IModel / Model vs. Model / ObjectModel or > Model / ModelImpl > > Ryan Gravener > http://bit.ly/no_word_docs > > > > On Fri, Oct 2, 2009 at 9:25 PM, Matej Knopp wrote: >> Easier? How's that? I find it really annoying that when I'm looking >> for something and I have to know upfront whether it is an interface or >> a class. And when reading the code, what difference does it really >> make if it is interface or a class? By that logic we should start >> using hungarian notation. You could easily see what type the class >> member is... >> >> -Matej >> >> On Sat, Oct 3, 2009 at 1:55 AM, Ryan Gravener wrote: >>> -1 It's nice to know what is an interface by seeing the I. Also for >>> IDEs its easier to find the class I'm looking for. >>> >>> >>> Ryan Gravener >>> http://bit.ly/no_word_docs >>> >>> >>> >>> On Fri, Oct 2, 2009 at 7:37 PM, Matej Knopp wrote: On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: > what about upgrading projects from 1.4 to 1.5 ? > It breaks compatibility There will be other breaks. This is not a minor update. Breaks compatibility is hardly a valid argument here. We will break compatibility one way or another. But we will also provide migration path. Replacing Model with ObjectModel and then IModel with Model in code (just an made up example) is hardly a task that would prevent anyone from migrating application to 1.5. -Matej > > -1 > > Not: i am not a *committer* but loves wicket :) > > 2009/10/3 Matej Knopp > >> 1.5 is going to be neither source nor binary compatible. And I >> wouldn't say that consistency and conventions is not a reason. >> >> -Matej >> >> On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: >> > -1 >> > >> > It breaks compatibility for absolutely no reason. >> > >> > >> > >> > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom >> > wrote: >> > >> >> +1 >> >> >> >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg >> 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 >> >>> >> >> >> > >> > > > > -- > Altuğ. > >>> >> >
Re: taking the I out of Interface
It's just my preference. IModel / Model vs. Model / ObjectModel or Model / ModelImpl Ryan Gravener http://bit.ly/no_word_docs On Fri, Oct 2, 2009 at 9:25 PM, Matej Knopp wrote: > Easier? How's that? I find it really annoying that when I'm looking > for something and I have to know upfront whether it is an interface or > a class. And when reading the code, what difference does it really > make if it is interface or a class? By that logic we should start > using hungarian notation. You could easily see what type the class > member is... > > -Matej > > On Sat, Oct 3, 2009 at 1:55 AM, Ryan Gravener wrote: >> -1 It's nice to know what is an interface by seeing the I. Also for >> IDEs its easier to find the class I'm looking for. >> >> >> Ryan Gravener >> http://bit.ly/no_word_docs >> >> >> >> On Fri, Oct 2, 2009 at 7:37 PM, Matej Knopp wrote: >>> On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: what about upgrading projects from 1.4 to 1.5 ? It breaks compatibility >>> There will be other breaks. This is not a minor update. Breaks >>> compatibility is hardly a valid argument here. We will break >>> compatibility one way or another. But we will also provide migration >>> path. Replacing Model with ObjectModel and then IModel with Model in >>> code (just an made up example) is hardly a task that would prevent >>> anyone from migrating application to 1.5. >>> >>> -Matej >>> -1 Not: i am not a *committer* but loves wicket :) 2009/10/3 Matej Knopp > 1.5 is going to be neither source nor binary compatible. And I > wouldn't say that consistency and conventions is not a reason. > > -Matej > > On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > > -1 > > > > It breaks compatibility for absolutely no reason. > > > > > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > > > >> +1 > >> > >> > >> On Oct 2, 2009, at 17:28, Igor Vaynberg > 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 > >>> > >> > > > -- Altuğ. >>> >> >
Re: taking the I out of Interface
Easier? How's that? I find it really annoying that when I'm looking for something and I have to know upfront whether it is an interface or a class. And when reading the code, what difference does it really make if it is interface or a class? By that logic we should start using hungarian notation. You could easily see what type the class member is... -Matej On Sat, Oct 3, 2009 at 1:55 AM, Ryan Gravener wrote: > -1 It's nice to know what is an interface by seeing the I. Also for > IDEs its easier to find the class I'm looking for. > > > Ryan Gravener > http://bit.ly/no_word_docs > > > > On Fri, Oct 2, 2009 at 7:37 PM, Matej Knopp wrote: >> On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: >>> what about upgrading projects from 1.4 to 1.5 ? >>> It breaks compatibility >> There will be other breaks. This is not a minor update. Breaks >> compatibility is hardly a valid argument here. We will break >> compatibility one way or another. But we will also provide migration >> path. Replacing Model with ObjectModel and then IModel with Model in >> code (just an made up example) is hardly a task that would prevent >> anyone from migrating application to 1.5. >> >> -Matej >> >>> >>> -1 >>> >>> Not: i am not a *committer* but loves wicket :) >>> >>> 2009/10/3 Matej Knopp >>> 1.5 is going to be neither source nor binary compatible. And I wouldn't say that consistency and conventions is not a reason. -Matej On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > -1 > > It breaks compatibility for absolutely no reason. > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > >> +1 >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >>> >> > >>> >>> >>> >>> -- >>> Altuğ. >>> >> >
Re: taking the I out of Interface
for people who are going to say that this is going to break compatibility: please look through your code and count the number of places where you implement a wicket-specific interface directly. we would like to know how often and what these interfaces are. thanks, -igor On Fri, Oct 2, 2009 at 3:28 PM, Igor Vaynberg 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 >
Re: taking the I out of Interface
we dont do these annoying refactors for no reason. we do not like something about the code and want to fix it. as far as migration pains we can ease that. take IRequestCycleProcessor as an example. we can create interface RequestCycleProcessor extends IRequestCycleProcessor and deprecate IRequestCycleProcessor. release this as 1.5.0.migration jar and then release 1.5.0 with IRequestCycleProcessor removed. this gives you as much time as you want to migrate your code. -igor On Fri, Oct 2, 2009 at 4:14 PM, tetsuo wrote: > -1 > > It breaks compatibility for absolutely no reason. > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > >> +1 >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >>> >> >
Re: taking the I out of Interface
thats what migration notes are for most people do not use the I convention in their apps, so it is pretty annoying for them to deal with this. and for those who do they are already used to doing something different because they are using other libs that do not use the convention. -igor On Fri, Oct 2, 2009 at 5:48 PM, Altuğ B. Altıntaş wrote: > Also It brings extra learning curve process; i thinks that's the major > update > IModel will be Model ? himm > > 2009/10/3 Matej Knopp > >> On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş >> wrote: >> > what about upgrading projects from 1.4 to 1.5 ? >> > It breaks compatibility >> There will be other breaks. This is not a minor update. Breaks >> compatibility is hardly a valid argument here. We will break >> compatibility one way or another. But we will also provide migration >> path. Replacing Model with ObjectModel and then IModel with Model in >> code (just an made up example) is hardly a task that would prevent >> anyone from migrating application to 1.5. >> >> -Matej >> >> > >> > -1 >> > >> > Not: i am not a *committer* but loves wicket :) >> > >> > 2009/10/3 Matej Knopp >> > >> >> 1.5 is going to be neither source nor binary compatible. And I >> >> wouldn't say that consistency and conventions is not a reason. >> >> >> >> -Matej >> >> >> >> On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: >> >> > -1 >> >> > >> >> > It breaks compatibility for absolutely no reason. >> >> > >> >> > >> >> > >> >> > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom >> wrote: >> >> > >> >> >> +1 >> >> >> >> >> >> >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg >> >> 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 >> >> >>> >> >> >> >> >> > >> >> >> > >> > >> > >> > -- >> > Altuğ. >> > >> > > > > -- > Altuğ. >
Re: taking the I out of Interface
i suppose we should start naming all our abstract classes with an A, so maybe AListView, nice to know its abstract and you have to implement something just by looking at the class name :) personally when i am looking for a requestcycleprocessor something its a lot easier to type in RequestCycleProcessor into the ide and not have to guess if there is an I in the front. -igor On Fri, Oct 2, 2009 at 4:55 PM, Ryan Gravener wrote: > -1 It's nice to know what is an interface by seeing the I. Also for > IDEs its easier to find the class I'm looking for. > > > Ryan Gravener > http://bit.ly/no_word_docs > > > > On Fri, Oct 2, 2009 at 7:37 PM, Matej Knopp wrote: >> On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: >>> what about upgrading projects from 1.4 to 1.5 ? >>> It breaks compatibility >> There will be other breaks. This is not a minor update. Breaks >> compatibility is hardly a valid argument here. We will break >> compatibility one way or another. But we will also provide migration >> path. Replacing Model with ObjectModel and then IModel with Model in >> code (just an made up example) is hardly a task that would prevent >> anyone from migrating application to 1.5. >> >> -Matej >> >>> >>> -1 >>> >>> Not: i am not a *committer* but loves wicket :) >>> >>> 2009/10/3 Matej Knopp >>> 1.5 is going to be neither source nor binary compatible. And I wouldn't say that consistency and conventions is not a reason. -Matej On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > -1 > > It breaks compatibility for absolutely no reason. > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > >> +1 >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >>> >> > >>> >>> >>> >>> -- >>> Altuğ. >>> >> >
Re: taking the I out of Interface
Also It brings extra learning curve process; i thinks that's the major update IModel will be Model ? himm 2009/10/3 Matej Knopp > On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş > wrote: > > what about upgrading projects from 1.4 to 1.5 ? > > It breaks compatibility > There will be other breaks. This is not a minor update. Breaks > compatibility is hardly a valid argument here. We will break > compatibility one way or another. But we will also provide migration > path. Replacing Model with ObjectModel and then IModel with Model in > code (just an made up example) is hardly a task that would prevent > anyone from migrating application to 1.5. > > -Matej > > > > > -1 > > > > Not: i am not a *committer* but loves wicket :) > > > > 2009/10/3 Matej Knopp > > > >> 1.5 is going to be neither source nor binary compatible. And I > >> wouldn't say that consistency and conventions is not a reason. > >> > >> -Matej > >> > >> On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > >> > -1 > >> > > >> > It breaks compatibility for absolutely no reason. > >> > > >> > > >> > > >> > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom > wrote: > >> > > >> >> +1 > >> >> > >> >> > >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg > >> 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 > >> >>> > >> >> > >> > > >> > > > > > > > > -- > > Altuğ. > > > -- Altuğ.
Re: taking the I out of Interface
-1 It's nice to know what is an interface by seeing the I. Also for IDEs its easier to find the class I'm looking for. Ryan Gravener http://bit.ly/no_word_docs On Fri, Oct 2, 2009 at 7:37 PM, Matej Knopp wrote: > On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: >> what about upgrading projects from 1.4 to 1.5 ? >> It breaks compatibility > There will be other breaks. This is not a minor update. Breaks > compatibility is hardly a valid argument here. We will break > compatibility one way or another. But we will also provide migration > path. Replacing Model with ObjectModel and then IModel with Model in > code (just an made up example) is hardly a task that would prevent > anyone from migrating application to 1.5. > > -Matej > >> >> -1 >> >> Not: i am not a *committer* but loves wicket :) >> >> 2009/10/3 Matej Knopp >> >>> 1.5 is going to be neither source nor binary compatible. And I >>> wouldn't say that consistency and conventions is not a reason. >>> >>> -Matej >>> >>> On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: >>> > -1 >>> > >>> > It breaks compatibility for absolutely no reason. >>> > >>> > >>> > >>> > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: >>> > >>> >> +1 >>> >> >>> >> >>> >> On Oct 2, 2009, at 17:28, Igor Vaynberg >>> 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 >>> >>> >>> >> >>> > >>> >> >> >> >> -- >> Altuğ. >> >
Re: taking the I out of Interface
On Sat, Oct 3, 2009 at 1:29 AM, Altuğ B. Altıntaş wrote: > what about upgrading projects from 1.4 to 1.5 ? > It breaks compatibility There will be other breaks. This is not a minor update. Breaks compatibility is hardly a valid argument here. We will break compatibility one way or another. But we will also provide migration path. Replacing Model with ObjectModel and then IModel with Model in code (just an made up example) is hardly a task that would prevent anyone from migrating application to 1.5. -Matej > > -1 > > Not: i am not a *committer* but loves wicket :) > > 2009/10/3 Matej Knopp > >> 1.5 is going to be neither source nor binary compatible. And I >> wouldn't say that consistency and conventions is not a reason. >> >> -Matej >> >> On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: >> > -1 >> > >> > It breaks compatibility for absolutely no reason. >> > >> > >> > >> > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: >> > >> >> +1 >> >> >> >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg >> 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 >> >>> >> >> >> > >> > > > > -- > Altuğ. >
Re: taking the I out of Interface
what about upgrading projects from 1.4 to 1.5 ? It breaks compatibility -1 Not: i am not a *committer* but loves wicket :) 2009/10/3 Matej Knopp > 1.5 is going to be neither source nor binary compatible. And I > wouldn't say that consistency and conventions is not a reason. > > -Matej > > On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > > -1 > > > > It breaks compatibility for absolutely no reason. > > > > > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > > > >> +1 > >> > >> > >> On Oct 2, 2009, at 17:28, Igor Vaynberg > 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 > >>> > >> > > > -- Altuğ.
Re: taking the I out of Interface
1.5 is going to be neither source nor binary compatible. And I wouldn't say that consistency and conventions is not a reason. -Matej On Sat, Oct 3, 2009 at 1:14 AM, tetsuo wrote: > -1 > > It breaks compatibility for absolutely no reason. > > > > On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > >> +1 >> >> >> On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >>> >> >
Re: taking the I out of Interface
-1 It breaks compatibility for absolutely no reason. On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom wrote: > +1 > > > On Oct 2, 2009, at 17:28, Igor Vaynberg 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 >> >
Re: taking the I out of Interface
+1 On Oct 2, 2009, at 17:28, Igor Vaynberg 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
Re: taking the I out of Interface
+1 for the I to go away. Feels too foreign. And against conventions. -Matej On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg 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 >
