There were two reasons to use Hungarian notation in C:
1. In C, you had to declare all your variables at the start of a function. So, if you have a 100 line function (not uncommon in C), and come across a new variable on line 70, you don't want to have to scroll all the way up to see what it is.
2. Distinguishing between pointer types and arrays.
C++ got rid of the first problem, and Java got rid of the second problem (Dad, what's a pointer?)
Of course, I still get the urge to start static variables with an s, e.g. "sMyStatic".
And then of course, there is the long winded Neo-Hungarian notation used by most of us:
Page page = new Page();
or
FunkyCoolClass funkyCoolObject = ....
'Nuff said,
Jonathan O'Connor
XCOM Dublin
Erik Hatcher <[EMAIL PROTECTED]>
22/04/2005 14:47
|
|
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]
