Curly braces MUST be lined up!!! And tabs should be banned from all but wordprocessing documents.
-----Original Message----- From: Jamie [mailto:[EMAIL PROTECTED] Sent: Fri 4/22/2005 8:26 AM To: Tapestry users Subject: Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much 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]
