I in prefixes:
A mistake, but there are no plans to strip it out of existing interfaces.
Breaks backwards compatibility. Perhaps in Tapestry Dali.
_ for variable names:
I like to be able to quickly pick out instance variables from locals /
parameters. The underscore notation helps with that, and with
name completion in IDEs. Pick your poison: "this.that" or "_that". I prefer
the latter. Jamie: this bugs you, but Ruby naming conventions don't?
indentation:
I like my braces to line up.
extra modifiers:
I like "public void foo()" on my interface methods even when "void foo()" is
enough. On the other hand, I don't like "abstract foo()" for interface
methods.
What the world needs:
Source code should be stored in a representational form and dynamically
translated and formatted dynamically by the IDE according to per-user
choices for all these things. Good luck with that.
On 4/22/05, Jamie <[EMAIL PROTECTED]> wrote:
>
> LOL. And +1 ;-
> Jamier
>
> 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]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
