On Apr 22, 2005, at 7:05 AM, Mind Bridge wrote:
By the very same logic we should also remove the '_' prefix from
member variables as well and make them look the same as local
variables, no?
Well, I certainly don't use _ prefixes :) I think its hideous.
But the difference is that the I-prefixes are external API whereas the
_junk is internal. The external interface is what folks see and use.
Folks that just look at tapestry-3.xx.jar do not see the internal
_stuff.
Hungarian notation does have its uses.
Bah! Not in Java it doesn't.
You say that it is redundant to have 'I' when you already have
declared the type as an 'interface'. The problem is that 'interface'
is declared in another file. Having to load/understand that other file
in addition to what you are doing at the moment is problematic.
I don't buy it. It is not problematic at all. Why does anyone need to
know that there is an interface or a class under it anyway? Show me a
use case where it matters. It certainly doesn't matter what I get back
here:
IPage page = cycle.getPage("Foo")
Why does the developer using this construct need to know or even care
what is returned?
In a company that can standardise on an IDE (or a set of IDEs) it
probably makes sense to relax rules like that a little bit as the IDEs
can compensate. I strongly disagree that this can be done in an
open-source project when there is a good alternative however. At the
very least that places a limitation on the people who join and the
tools they employ.
Show me one other Java open source project that employs Hungarian
syntax. None that I use but Tapestry.
I agree that the matter is more or less closed, as Howard has already
decided to remove the 'I's from Tapestry and given that he writes the
majority of the code, his opinion does matter a lot. I should have
spoken out when there was a vote on that in tapestry-dev (was there
one actually?). Nevertheless, what I am saying may be of consideration
in the future.
I respect your opinions as much as Howard's, but I still reserve the
right to disagree :) Hungarian notation seemed to have it's place in C
coding, but only in Tapestry have I seen it in Java. Should we start
calling variables like this:
String sName = "Erik";
too?! ;)
Erik
Erik Hatcher wrote:
On Apr 22, 2005, at 5:53 AM, Mind Bridge wrote:
Hi,
Do you have to 'implement' or 'extend' a particular type? Can you
have multiple inheritance with that type or not? Can you instantiate
it?
The answers of those questions are clear with 'IPage'. If 'Page' can
be both a class or an interface, you have to look through the code
to find that out.
Interfaces and classes are two rather different concepts. It seems
to me that they need to be distinguished clearly. Removing the 'I'
in front of the name and the characters that saves are a much
smaller win compared to the loss of clarity and the time wasted in
figuring out what can be done with that type.
I disagree. Putting an "I" in front of something that is declared as
an "interface" already is redundant. My IDEs (I juggle between
Eclipse and IDEA) both easily show me what kind of beast a particular
reference is if I want to know. In most cases its irrelevant whether
you're dealing with one or the other. Tapestry is the exception here
- no other API I work with uses this old-school Hungarian notation.
It's not really worth dwelling on, though. Howard has already agreed
that moving forward the I-prefix will be dropped for new code. The
question now is what to do about the existing interfaces. Putting a
cleaner name in interface hierarchy (RequestCycle extends
IRequestCycle, or vice versa) and deprecating the I-prefixed stuff
seems to make sense. This will be ugly though - as method signatures
using those interfaces will need to be duplicated with the old one
deprecated - right?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 4/21/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
