db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: [rfc] Do we need a naming standard ?
Date Thu, 14 Apr 2005 12:43:33 GMT
> 1) Because an interface is a type, a class is a type which can also
> have some implementation, and being able to change these around without
> being left with bizarro naming artifacts is a big plus.
> 2) Because it is really ugly without adding anything of significant
> value. Knowing if it is an interface or not is pretty much useless when
> you are using it -- it is only possibly useful when you are
> extending/implementing it (or doing proxy voudoun, but you can do that
> for classes very easily as well) and then you have to look at it
> anyway.

This might be true for C++ where there is no real distinction between
interfaces and classes due to multiple inheritance. But for Java the
I-convention actually has one important benefit: you can derive from
the name only (no need for an IDE or Javadoc) that this is an
Of course this has only significance if the fact that it is an
interface, is important. Within Eclipse for instance, this nicely
communicates in the code that you're working against interfaces.
But then again, the I-convention was merely an example of such a
naming standard that we might use.

> I also dislike the Foo / FooImpl convention. If you only ever have one
> impl, don't bother with an interface. If you expect multiple
> implementations then there should be something different about the
> implementations --- in which case a more descriptive name is a Good
> Thing.

The reason that I brought this up (and I'm not advertising the
I-convention btw.) is that we have several of these
customizable/pluggable components and currently they have no
consistent naming scheme.
> These are nits, and we can obviously work with whatever form is used
> (heck we have lots of code of the form m_thingie for instance vars) and
> having an expected standard is a Good Thing. I just don't like those
> particular idioms.

Right you are, these m_someField (and for that matter _someField)
could be removed as well. But they are not visible to the user, so we
can handle them as we go, so to speak.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message