LOL. And +1 ;-)
Jamie
Viktor Szathmary wrote:
Hi,
let me put some more fuel on the flamewar :) I'm Hungarian, and I'm pretty sure Charles Simonyi would agree that, with a language like Java, Hungarian notation is pointless... and the underscore notation in Tapestry is in fact hideous...
I personally like the I prefix for interfaces, but can live without them.. If you don't use that prefix, you'll end up suffixing Impl to a bunch of simple classes... so whatever, I don't really var, just don't break my existing code for the sake of prettier names, that's all I care about :)
Oh, and the curly braces should start on the same line... and I like tabs... 4 character wide... That's the One True Way :)
regards, viktor
On 4/22/05, Erik Hatcher <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- 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]
