+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
> probl
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
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 D
> 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
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.
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.
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 / approximat
> >
> > 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 :
her 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.
> >
> >
>
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 fortu
inion 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 beca
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.
>
> 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,
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
>
> 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
p
ore 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.
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.
>
>
e.
>>
>> 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.
> 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 u
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 e
8, 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?
>>>>
>>>&
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
>
> 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,
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 abou
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..
O
>
> 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
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 w
+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 (p
-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 Mart
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
-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 eve
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
+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
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
> 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
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
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
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
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 w
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 becau
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 refe
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 emphasiz
+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
>> sa
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 Vaynb
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
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 n
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
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
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
+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
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 ev
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 migr
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 renamin
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.va
n/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 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 applica
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. Tape
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
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
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.
>
>
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
>
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
-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
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 Locato
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
>
+1
(non-binding)
--
AT®
> "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
-1
"If it ain't broken, don't try to fix it."
**
Martin
-
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 p
+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
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
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
wro
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 s
-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
-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
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 wi
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 whe
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. Y
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
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 IReque
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, O
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 RequestCyclePro
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 br
-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 upgrad
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
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
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 wro
-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
+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
aw3s0
+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 ti
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 s
91 matches
Mail list logo
