You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Hensley, Richard" <Ri...@McKesson.com> on 2005/04/21 23:03:44 UTC
RE: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Actually, last time I checked in with the committers, all of the I's in
the interfaces were being removed. In my opinion a good thing, reminds
me to much of my COM days and makes me twitch.
_____
From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
Sent: Thursday, April 21, 2005 1:51 PM
To: tapestry-user@jakarta.apache.org
Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
I would like "I" prefix to go in the interface name. As a user of
Tapestry, why should I care if RequestCycle is an interface or class
(implementation).
Sent using Mail2Forum (http://www.mail2forum.com) Read this topic online
here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
<http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Olivier Bourgeois <ze...@wanadoo.fr>.
On Friday 22 April 2005 12:36, 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.
Erik, I just would like to mention that there is another open source project
which uses the "I" prefix for interfaces : this is the Eclipse IDE.
So maybe Tapestry is (was) not that old fashioned after all ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Mind Bridge <mi...@yahoo.com>.
No, they do not.
They would, if classes and interfaces were colored differently.
Instead they provide you with the ability to quickly go to the source
code of the type and see whether it is an interface or a class. You have
to undertake an action -- it is fast, but it is still a distraction.
Also, I do not think that "most IDEs do that" is a good enough
justification when there an alternative. I do occasionally write code
without an IDE for example.
Ivano wrote:
> Doesn't seem a meaninful remark since most IDEs give you the tools
> needed to flash out the difference with no effort.
> My 2s.
>
> Ivano
>
> 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.
>>
>>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Ivano <i....@mclink.it>.
Doesn't seem a meaninful remark since most IDEs give you the tools
needed to flash out the difference with no effort.
My 2s.
Ivano
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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Karthik Abram <ka...@neovera.com>.
Well then, in the same way, putting "Abstract" in front of a class that is
abstract is equally meaningless. My IDE shows me that too!!
-----Original Message-----
From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
Sent: Friday, April 22, 2005 6:37 AM
To: Tapestry users
Subject: Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Jamie <ja...@dang.com>.
Hey, I thought you were on vacation! :-D
Howard Lewis Ship wrote:
> 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 <ja...@dang.com> 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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by "T.Mikov" <tm...@gmail.com>.
Howard Lewis Ship wrote:
> I in prefixes:
>
> A mistake, but there are no plans to strip it out of existing interfaces.
> Breaks backwards compatibility. Perhaps in Tapestry Dali.
>
Why is it a mistake ? Is it just a matter of personal taste like the
brace indentation (although we all know that braces should line up ! :-)
or is there bigger justification ?
Personally until now I found "IBla" and "Bla" cleanear than "Bla" and
"BlaImpl". The argument that IDEs can show me the source quickly does
not really hold if I am reading a paper listing for example. People seem
to hate hungarian notation since they associate it with the dark days of
Windows 3.1 programming, but I prefer to stick to more rational
decisions :-)
Is there any reference that discusses this, or if you have time I would
really appreciate your opinion in a few lines.
regards,
Tzvetan
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ja...@dang.com> 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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>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: tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Eli Doran <el...@gmail.com>.
insert 2 cents here...
I agree that the 'I' prefix is annoying to have to type over and over
again since you end up using the interface frequently. It doesn't
usually matter if you have to alter the name of an implementation class
to differentiate. You should be using the implemenation via the
interface, right? So you type that more often.
Also, I enjoy those underscores tremendously. ;) It makes it obvious
it's a member variable not a local or a method parameter. Also, I find
the usual:
this.someValue = someValue;
Very annoying and much prefer:
_someValue = someValue;
And of course, braces must go on the next line...
enjoy,
eli
Jamie wrote:
> 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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>>>>> tapestry-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Eli Doran <el...@gmail.com>.
insert 2 cents here...
I agree that the 'I' prefix is annoying to have to type over and over
again since you end up using the interface frequently. It doesn't
usually matter if you have to alter the name of an implementation class
to differentiate. You should be using the implemenation via the
interface, right? So you type that more often.
Also, I enjoy those underscores tremendously. ;) It makes it obvious
it's a member variable not a local or a method parameter. Also, I find
the usual:
this.someValue = someValue;
Very annoying and much prefer:
_someValue = someValue;
And of course, braces must go on the next line...
enjoy,
eli
Jamie wrote:
> 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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail:
>>>>> tapestry-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Jamie <ja...@dang.com>.
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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>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: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Guys, have you heard of jalopy http://jalopy.sourceforge.net/
Pass source through and enjoy! I think Jakarta should demand mandatory
Jalopy step in build files that everybody will be happy. No more heated
syntax discussions, end of story, everybody works with what Heorshe likes :)
Karthik Abram wrote:
>No more off the topic than the discussion on Ruby. At least this one
>pertains to Tapestry code :) Also, the Jakarta commons coding standard calls
>for braces on its own line.
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Karthik Abram <ka...@neovera.com>.
No more off the topic than the discussion on Ruby. At least this one
pertains to Tapestry code :) Also, the Jakarta commons coding standard calls
for braces on its own line.
-----Original Message-----
From: Jamie [mailto:jamie@dang.com]
Sent: Friday, April 22, 2005 3:46 PM
To: Tapestry users
Subject: Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
I could give equally compelling arguments as to why having an opening
curly brace on its own line is completely stupid, besides the fact that
it's way harder (for me) to read (to echo your exclamation, I find this
style completely unreadable!), but what's the point? This topic has been
argued ad nauseum by proponents of each style forever and there's no
point continuing it here.
Besides, we've gotten way off topic!
How about we get back to Tapestry?
Jamie
Karthik Abram wrote:
>
> Oh, and the curly braces should start on the same line... and I like
> tabs... 4 character wide... That's the One True Way :)
>
>
> On this one, I STRONGLY disagree. Of the four brace styles (k&r, gnu, bsd,
> whitesmith), k&r (which is what Java uses) is the most ridiculous. It
makes
> the code completely unreadable! By putting the opening brace next to the
> control statement, you are making it part of the control statement. It is
> not! The language does not dictate that a for loop or a while loop starts
> with the for statement and ends with } which is precisely what:
>
> for (..) {
> stmt;
> stmt;
> }
>
> makes it look like!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Jamie <ja...@dang.com>.
I could give equally compelling arguments as to why having an opening
curly brace on its own line is completely stupid, besides the fact that
it's way harder (for me) to read (to echo your exclamation, I find this
style completely unreadable!), but what's the point? This topic has been
argued ad nauseum by proponents of each style forever and there's no
point continuing it here.
Besides, we've gotten way off topic!
How about we get back to Tapestry?
Jamie
Karthik Abram wrote:
>
> Oh, and the curly braces should start on the same line... and I like
> tabs... 4 character wide... That's the One True Way :)
>
>
> On this one, I STRONGLY disagree. Of the four brace styles (k&r, gnu, bsd,
> whitesmith), k&r (which is what Java uses) is the most ridiculous. It makes
> the code completely unreadable! By putting the opening brace next to the
> control statement, you are making it part of the control statement. It is
> not! The language does not dictate that a for loop or a while loop starts
> with the for statement and ends with } which is precisely what:
>
> for (..) {
> stmt;
> stmt;
> }
>
> makes it look like!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Karthik Abram <ka...@neovera.com>.
Oh, and the curly braces should start on the same line... and I like
tabs... 4 character wide... That's the One True Way :)
On this one, I STRONGLY disagree. Of the four brace styles (k&r, gnu, bsd,
whitesmith), k&r (which is what Java uses) is the most ridiculous. It makes
the code completely unreadable! By putting the opening brace next to the
control statement, you are making it part of the control statement. It is
not! The language does not dictate that a for loop or a while loop starts
with the for statement and ends with } which is precisely what:
for (..) {
stmt;
stmt;
}
makes it look like!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Viktor Szathmary <ph...@gmail.com>.
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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >
> > --
> > 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Jamie <ja...@dang.com>.
I have to agree with Erik's points here. I'll had that I find Hungarian
notation and _ prefixes almost impossible to read. They slow me down
terribly when I am reading code. They catch my eye, make me stop and
wonder what the hell I'm looking at. The ugliness and verbosity makes
the code more difficult to understand rather than easier.
Jamie
Erik Hatcher 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: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Hungarian Notation: was If we call it Tapestry 4.0, not 3.x, Maybe we would
do much [ndc] [auf Viren geprueft]
Posted by Jonathan O'Connor <Jo...@xcom.de>.
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
<erik@ehatchersol
utions.com> To
"Tapestry users"
22/04/2005 14:47 <ta...@jakarta.apache.org>
cc
Please respond to Subject
"Tapestry users" Re: If we call it Tapestry 4.0, not
<tapestry-user@ja 3.x, Maybe we would do much [auf
karta.apache.org> Viren geprueft]
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: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
> --
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
> --
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Mind Bridge <mi...@yahoo.com>.
Hi Erik,
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?
Hungarian notation does have its uses.
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.
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.
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.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Maik Dobryn <ma...@dobryn.de>.
Programming against interfaces is a common and well known pattern, in
this way I find it more natural to work with I-less interfaces.
In every day Tapestry business there are only a couple of intefaces to
handle with. If someone is in doubt, it takes a few seconds to have a
look in the API docs.
It would be interesting how many other projects prefer I-identified
versions.
Maik
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.
>
> Just my opinion....
> -mb
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by "T.Mikov" <tm...@gmail.com>.
The same logic would seem to apply for IPage and Page, doesn't it ? One
is an interface, while the other is an implementation that could be used
or extended.
Howard Lewis Ship wrote:
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
>
> On 4/23/05, Kent Tong <ke...@cpttm.org.mo> wrote:
>
>>Karthik Abram <karthik.abram <at> neovera.com <http://neovera.com>>
>>writes:
>>
>>
>>>So why does having "Abstract" in an abstract class make sense? Clearly
>>>"public abstract class" is equally unequivocal.
>>
>>That's right. In my opinion names like AbstractEngine, AbstractPage are
>>poor names. For example, AbstractPage should just be called DefaultPage
>>or something else.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
Ideally a name should tell you two things:
Function
Implementation
IFoo tells you nothing about function, but tells you a lot about
implementation (it's an interface).
AbstractDieselEngine tells you A) it's a diesel engine and B) it's
abstract.
DieselEngine tells you A) it's a diesel engine and B) it's concrete
(but only if your convention is that "naked" names indicate concreteness.
If we're looking for a way to determine behavior (function)
differences based on names, I don't think prefix or suffix conventions are
going to do the job. These sorts of conventions are, imho, good at
describing implementation, but near useless at describing function.
That's a whole other question e.g. how to assign functionally
meaningful names.
--- Pat
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Kent Tong
Sent: Monday, April 25, 2005 6:32 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: Naming intefaces and abstract classes
Patrick Casey <patcasey <at> adelphia.net> writes:
> > What if later you have a DieselEngine class (probably
> > implementing AbstractDieselEngine), how can you tell
> > the semantic difference between the two?
>
> I'm not sure I understand what you're asking here.
I'm saying if we have both DieselEngine and AbstractDieselEngine,
how can we tell their behavioral difference from their names?
For example, we have both Map and HashMap, from their names we
know that HashMap is using hashing to implement the map. So
the behavioral difference between Map and HashMap is pretty
clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Patrick Casey <patcasey <at> adelphia.net> writes:
> > What if later you have a DieselEngine class (probably
> > implementing AbstractDieselEngine), how can you tell
> > the semantic difference between the two?
>
> I'm not sure I understand what you're asking here.
I'm saying if we have both DieselEngine and AbstractDieselEngine,
how can we tell their behavioral difference from their names?
For example, we have both Map and HashMap, from their names we
know that HashMap is using hashing to implement the map. So
the behavioral difference between Map and HashMap is pretty
clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Eli Doran <el...@gmail.com>.
I believe the difference between using the prefix with ISomeName and
AbstractSomeName is that you commonly use the interface to refer to an
instance but you do not refer to an instance using the Abstract* name.
So the "I" prefix is undesirable because of frequent use. The "Abstract"
prefix denotes an important distinction and even dissuades people from
using its name.
For example, we frequenly use Map to refer to map instances. How often
do we refer to them as AbstractMap ? Sometimes you do need to access the
concrete class and in this case, HashMap, it is a good name. It would
not be as *nice* to type IMap often or use MapImpl. Also, Naming
AbstractMap BaseMap or DefaultMap hides that it's a partial
implementation. Base* and Default* are good uses to define the commonly
used implementation of the interface its name implies exists. It also
shows that it was written to be extended or swapped out for a completely
different implementation of the interface.
I like it this way :)
enjoy,
eli
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
<snip>
> AbstractEngine
> AbstractDieselEngine
> AbstractTurbineEngine
> AbstractPistonEngine
>
> ....
>
> At least that's the convention I generally go with.
What if later you have a DieselEngine class (probably
implementing AbstractDieselEngine), how can you tell
the semantic difference between the two?
I'm not sure I understand what you're asking here. When we're reading API
type code we're likely to run into either:
AbstractDieselEngine anEngine = (AbstractDieselEngine) MotorPool.getNext();
Or (more rarely in code using an API)
DieselEngine d = new DieselEngine();
In the former context, we don't care what the concrete class name is because
we're casting the class as abstract. We do however get a useful hint that
anEngine is an abstraction which we wouldn't get without the leading
Abstract in the classname.
In the latter case we know its concrete because we can see the constructor.
So in each case we have sufficient information to understand the code.
Or are you hoping to develop a naming convention that includes a hint for
concreteness in the name e.g. ConcreteDieselEngine? (I've read code like
that before and never liked it. It seems easier and more natural to me at
least to assume concreteness in the absence of other modifiers, but as
others have pointed out ymmv).
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Patrick Casey <patcasey <at> adelphia.net> writes:
> > This is fine until we need a subclass extending AbstractEngine that
> > still keeps some methods abstract. Then we'll have trouble naming
> > that subclass because they're abstract too.
>
> AbstractEngine
> AbstractDieselEngine
> AbstractTurbineEngine
> AbstractPistonEngine
>
> ....
>
> At least that's the convention I generally go with.
What if later you have a DieselEngine class (probably
implementing AbstractDieselEngine), how can you tell
the semantic difference between the two?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Excellent comments, Brian.
Jamie
On Apr 24, 2005, at 1:40 AM, Brian K. Wallace wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think, aside from the brace positioning, we're going around in
> circles
> on things about which we just need to agree to disagree. If you have
> one
> developer, and one only, you're most likely to find a unanimous vote
> for
> or against names, or braces, or variables - but only "most likely".
> Things I do today are not what I see in code I wrote 10 years ago -
> part
> is experience - part is personal taste. Now we look at not just "more
> than one" developer, but a world-wide community? OMG if we could only
> get a unanimous vote for *anything* with diversity like that.
>
> I personally detest "I" for interfaces and "_" for variable prefixes.
> I'm not fond of "braces should line up" but it's better than seeing "I"
> in front of every interface. And I really like having "Abstract" ahead
> of anything... well... abstract. That said, I detest paying so much for
> gas and dealing with people who have no clue yet claim to be the
> "expert". Do I buy gas? yes. Do I deal with such people? yes. And I put
> "I" ahead of interfaces and use "_" as prefixes (for class-level) and
> my
> braces line up. Why? Because it works. I've grown very tired of "Impl"
> suffixes, and if you use "Page" for the interface, and you code only
> one
> implementation - what is it? BasePage? No, we went all the way and
> aren't using "Abstract" to denote an abstract class and BasePage
> already
> exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
> your files: Page, BasePage, and DefaultPage. Without opening up your
> IDE
> - - what is what? And now we start adding more and more
> interfaces/abstract classes/implementations. What is "nice" ends up
> being an IDE-preferred view of the world. I love Eclipse (as others,
> I'm
> sure, love their IDE), but I do *occasionally* look at the JavaDoc even
> for projects where I'm the only person working on it - even more so for
> projects I do no development on. You can say "just look at the code -
> it's open source - that's the beauty of open source". And I'll say "no
> thank you - I just need clarification on the API". (Then I find out, of
> course, that since it's "open source" the JavaDoc sucks and I _have_ to
> look at the source [personal pet peeve about bad/lacking documentation
> for many projects, not just OS - as noted by many users and
> acknowledged
> by many developers], but that's missing the point.)
>
> I'd much rather have my interfaces grouped with my default
> implementation (which "Page" and "PageImpl" provides in my lovely IDE),
> but when every other file or so is "Impl" this or "Impl" that - *ugh*.
> I
> also like having my API jar'ed up separate from my implementation in
> some instances - completely throws my "grouped together" out the window
> if I have two separate source paths in "my lovely IDE". We give, we
> take, we drive on. I don't think most users care as much about the
> class/interface naming conventions as the do about API method naming
> ("rewind" anyone? - no dig there Howard, just that it's the single most
> 'misunderstood' method I see on the list). As a developer, I love
> knowing that any abstract class starts with "Abstract" - I'm a
> key-phrase junkie. "Starts with Abstract - hmmm... might have to
> subclass that one" - seems pretty simple to me. "AbstractDieselEngine"
> -
> hmmm... Bet I could subclass that one for a DieselEngine
> implementation.
> No JavaDoc needed, no source code to peruse at my leisure. Does that
> mean that I wouldn't work with "Engine" as the abstract, and "DEngine"
> as an abstract implementation of "Engine" intended for "Diesel"
> engines?
> Nope. Sure doesn't. Just nicer as a personal - non-IDE view the first
> way. And believe it or not, 99% of all developers I know have naming
> issues. "I have a class that does this, what should I name it?" It's an
> unwritten rule - you design, you code, you test (hopefully) - and you
> just run out of names that 1) apply and 2) make sense. But of those
> 99%,
> 100% don't really care how long it took me to name files any more than
> I
> care how long it took them. We do our best with what we have, and
> grumble about it later.
>
> So -
> +1 to any name you choose - we adapt and grumble about it regardless of
> what's chosen
> +1 to any code convention you choose - we adapt and grumble about it
> regardless of what's chosen
> - -1 to "but this is best because of my lovely IDE" - give a _real_
> answer
> not an IDE specific answer
> - -1 to breaking backward compatibility because "we've grown so we know
> now IPage is annoying where Page is not"
>
> and a resounding
> +1*** to "document it as a project level developer convention and
> revisit on the developer list if there are true (not imagined) reasons
> for changes." Hell, go ahead and document (as Howard has done) "This
> was
> a bad idea, but changing it would break compatibility." Nothing wrong
> with that. And those grumblings in the back with be there regardless.
>
> My .02... .03... $1.50
>
> Patrick Casey wrote:
> | Howard Lewis Ship <hlship <at> gmail.com> writes:
> |
> |
> |>The distinction, in my mind, is that AbstractEngine is incomplete
> (it has
> |>unimplemented abstract methods), while DefaultEngine would be a
> complete
> |>implementation that could be used as-is or extended.
> |
> |
> | This is fine until we need a subclass extending AbstractEngine that
> | still keeps some methods abstract. Then we'll have trouble naming
> | that subclass because they're abstract too.
> |
> | AbstractEngine
> | AbstractDieselEngine
> | AbstractTurbineEngine
> | AbstractPistonEngine
> |
> | ....
> |
> | At least that's the convention I generally go with.
> |
> |
> |
> | ---------------------------------------------------------------------
> | To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> | For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFCazFNaCoPKRow/gARAjetAJ9C08c+b3gdbv3G34Bu1OHi4CNvFACg03BH
> 9l5je5nOTUudEkbAHr8JAfU=
> =OCn9
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Brian K. Wallace <brian <at> transmorphix.com> writes:
> I think, aside from the brace positioning, we're going around in circles
> on things about which we just need to agree to disagree.
I agree the need to adopt a uniform coding convention for
a project. However, this doesn't contradict with the need
to discuss the pros and cons of the various coding
conventions.
> and if you use "Page" for the interface, and you code only one
> implementation - what is it? BasePage? No, we went all the way and
> aren't using "Abstract" to denote an abstract class and BasePage already
> exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
> your files: Page, BasePage, and DefaultPage. Without opening up your IDE
> what is what?
This is indeed a problem. We have to ask how DefaultPage/AbstractPage
differs from BasePage. If we're talking about the Tapestry, I think
AbstractPage should be called DefaultPage or BasePage, while
BasePage should be called HTMLPage.
Or better still, currently in my opinion Tapestry uses too much
inheritance. I believe by using delegation most of the naming difficulties
can be solved. For example, the only difference between AbstractPage
and BasePage is just the use of an HTMLWriter. If AbstractPage
used delegation:
class AbstractPage {
public AbstractPage() {
useHTMLWriter();
}
public AbstractPage(MarkupWriter writer) { ... }
public void useHTMLWriter() {
writer = new HTMLWriter();
}
public void useWAPWriter() {
writer = new WAPWriter();
}
}
Then we can eliminate BasePage entirely. Our regular pages can
be like:
class Home extends AbstractPage {
}
class WAPHome extends AbstractPage {
public WAPHome() {
useWAPWriter();
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think, aside from the brace positioning, we're going around in circles
on things about which we just need to agree to disagree. If you have one
developer, and one only, you're most likely to find a unanimous vote for
or against names, or braces, or variables - but only "most likely".
Things I do today are not what I see in code I wrote 10 years ago - part
is experience - part is personal taste. Now we look at not just "more
than one" developer, but a world-wide community? OMG if we could only
get a unanimous vote for *anything* with diversity like that.
I personally detest "I" for interfaces and "_" for variable prefixes.
I'm not fond of "braces should line up" but it's better than seeing "I"
in front of every interface. And I really like having "Abstract" ahead
of anything... well... abstract. That said, I detest paying so much for
gas and dealing with people who have no clue yet claim to be the
"expert". Do I buy gas? yes. Do I deal with such people? yes. And I put
"I" ahead of interfaces and use "_" as prefixes (for class-level) and my
braces line up. Why? Because it works. I've grown very tired of "Impl"
suffixes, and if you use "Page" for the interface, and you code only one
implementation - what is it? BasePage? No, we went all the way and
aren't using "Abstract" to denote an abstract class and BasePage already
exists as an Abstract class. How about "DefaultPage"? Ok. Now look at
your files: Page, BasePage, and DefaultPage. Without opening up your IDE
- - what is what? And now we start adding more and more
interfaces/abstract classes/implementations. What is "nice" ends up
being an IDE-preferred view of the world. I love Eclipse (as others, I'm
sure, love their IDE), but I do *occasionally* look at the JavaDoc even
for projects where I'm the only person working on it - even more so for
projects I do no development on. You can say "just look at the code -
it's open source - that's the beauty of open source". And I'll say "no
thank you - I just need clarification on the API". (Then I find out, of
course, that since it's "open source" the JavaDoc sucks and I _have_ to
look at the source [personal pet peeve about bad/lacking documentation
for many projects, not just OS - as noted by many users and acknowledged
by many developers], but that's missing the point.)
I'd much rather have my interfaces grouped with my default
implementation (which "Page" and "PageImpl" provides in my lovely IDE),
but when every other file or so is "Impl" this or "Impl" that - *ugh*. I
also like having my API jar'ed up separate from my implementation in
some instances - completely throws my "grouped together" out the window
if I have two separate source paths in "my lovely IDE". We give, we
take, we drive on. I don't think most users care as much about the
class/interface naming conventions as the do about API method naming
("rewind" anyone? - no dig there Howard, just that it's the single most
'misunderstood' method I see on the list). As a developer, I love
knowing that any abstract class starts with "Abstract" - I'm a
key-phrase junkie. "Starts with Abstract - hmmm... might have to
subclass that one" - seems pretty simple to me. "AbstractDieselEngine" -
hmmm... Bet I could subclass that one for a DieselEngine implementation.
No JavaDoc needed, no source code to peruse at my leisure. Does that
mean that I wouldn't work with "Engine" as the abstract, and "DEngine"
as an abstract implementation of "Engine" intended for "Diesel" engines?
Nope. Sure doesn't. Just nicer as a personal - non-IDE view the first
way. And believe it or not, 99% of all developers I know have naming
issues. "I have a class that does this, what should I name it?" It's an
unwritten rule - you design, you code, you test (hopefully) - and you
just run out of names that 1) apply and 2) make sense. But of those 99%,
100% don't really care how long it took me to name files any more than I
care how long it took them. We do our best with what we have, and
grumble about it later.
So -
+1 to any name you choose - we adapt and grumble about it regardless of
what's chosen
+1 to any code convention you choose - we adapt and grumble about it
regardless of what's chosen
- -1 to "but this is best because of my lovely IDE" - give a _real_ answer
not an IDE specific answer
- -1 to breaking backward compatibility because "we've grown so we know
now IPage is annoying where Page is not"
and a resounding
+1*** to "document it as a project level developer convention and
revisit on the developer list if there are true (not imagined) reasons
for changes." Hell, go ahead and document (as Howard has done) "This was
a bad idea, but changing it would break compatibility." Nothing wrong
with that. And those grumblings in the back with be there regardless.
My .02... .03... $1.50
Patrick Casey wrote:
| Howard Lewis Ship <hlship <at> gmail.com> writes:
|
|
|>The distinction, in my mind, is that AbstractEngine is incomplete (it has
|>unimplemented abstract methods), while DefaultEngine would be a complete
|>implementation that could be used as-is or extended.
|
|
| This is fine until we need a subclass extending AbstractEngine that
| still keeps some methods abstract. Then we'll have trouble naming
| that subclass because they're abstract too.
|
| AbstractEngine
| AbstractDieselEngine
| AbstractTurbineEngine
| AbstractPistonEngine
|
| ....
|
| At least that's the convention I generally go with.
|
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCazFNaCoPKRow/gARAjetAJ9C08c+b3gdbv3G34Bu1OHi4CNvFACg03BH
9l5je5nOTUudEkbAHr8JAfU=
=OCn9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
This is fine until we need a subclass extending AbstractEngine that
still keeps some methods abstract. Then we'll have trouble naming
that subclass because they're abstract too.
AbstractEngine
AbstractDieselEngine
AbstractTurbineEngine
AbstractPistonEngine
....
At least that's the convention I generally go with.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> The distinction, in my mind, is that AbstractEngine is incomplete (it has
> unimplemented abstract methods), while DefaultEngine would be a complete
> implementation that could be used as-is or extended.
This is fine until we need a subclass extending AbstractEngine that
still keeps some methods abstract. Then we'll have trouble naming
that subclass because they're abstract too.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Howard Lewis Ship <hl...@gmail.com>.
The distinction, in my mind, is that AbstractEngine is incomplete (it has
unimplemented abstract methods), while DefaultEngine would be a complete
implementation that could be used as-is or extended.
On 4/23/05, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Karthik Abram <karthik.abram <at> neovera.com <http://neovera.com>>
> writes:
>
> >
> > So why does having "Abstract" in an abstract class make sense? Clearly
> > "public abstract class" is equally unequivocal.
>
> That's right. In my opinion names like AbstractEngine, AbstractPage are
> poor names. For example, AbstractPage should just be called DefaultPage
> or something else.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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
RE: Naming intefaces and abstract classes
Posted by Patrick Casey <pa...@adelphia.net>.
I dunno, I kind of like having a hint as to the class type in the
name. That way if I see a reference in code or javadoc I know what it is
without having to dig up the source for the class in question. If I'm
reading some source and run into:
IPage p = (IPage) cycle.getPage("pageName")
I immediately know that cycle has a collection of object who
implement the IPage interface. Conversely, if I see:
Page p = (Page) cycle.getPage("pageName")
I assumed (potentially erroneously), that Page is a concrete class
as it's the natural assumption to make.
I agree when you're reading the primary source it's sort of
redundant, but most users of a package aren't going to read the primary
source. They'll end up reading the higher level API and sample code, where
having Abstract or I in the name is a useful crib as to what's going on.
It's sort of like using _ or f for field variables. Sure I could
scroll up to the top of the class and see if something is defined there or
not, but if the information is contained within the name, I don't have to.
--- Pat
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Kent Tong
Sent: Saturday, April 23, 2005 6:05 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: Naming intefaces and abstract classes
Karthik Abram <karthik.abram <at> neovera.com> writes:
>
> So why does having "Abstract" in an abstract class make sense? Clearly
> "public abstract class" is equally unequivocal.
That's right. In my opinion names like AbstractEngine, AbstractPage are
poor names. For example, AbstractPage should just be called DefaultPage
or something else.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Naming intefaces and abstract classes
Posted by Kent Tong <ke...@cpttm.org.mo>.
Karthik Abram <karthik.abram <at> neovera.com> writes:
>
> So why does having "Abstract" in an abstract class make sense? Clearly
> "public abstract class" is equally unequivocal.
That's right. In my opinion names like AbstractEngine, AbstractPage are
poor names. For example, AbstractPage should just be called DefaultPage
or something else.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Naming intefaces and abstract classes
Posted by Karthik Abram <ka...@neovera.com>.
So why does having "Abstract" in an abstract class make sense? Clearly
"public abstract class" is equally unequivocal.
-----Original Message-----
From: news [mailto:news@sea.gmane.org]On Behalf Of Kent Tong
Sent: Friday, April 22, 2005 9:25 PM
To: tapestry-user@jakarta.apache.org
Subject: Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Mind Bridge <mindbridgeweb <at> yahoo.com> writes:
> 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.
Using "I" is bad because it violates the DRY (Don't Repeat Yourself)
principle. If the fact that Foo is an interface is already stated
in:
interface Foo { ... }
There is no need to state it again in its name. Similarly, you won't
duplicate the methods in Foo into its name, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Kent Tong <ke...@cpttm.org.mo>.
Mind Bridge <mindbridgeweb <at> yahoo.com> writes:
> 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.
Using "I" is bad because it violates the DRY (Don't Repeat Yourself)
principle. If the fact that Foo is an interface is already stated
in:
interface Foo { ... }
There is no need to state it again in its name. Similarly, you won't
duplicate the methods in Foo into its name, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Mind Bridge <mi...@yahoo.com>.
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.
Just my opinion....
-mb
Andy Pahne wrote:
>
>I dislike the I in the interfaces, because if you follow the good
>practice of programming against interfaces, you always have to deal with
>this extra I. It's just more natural to code
>
> Page nextPage = cycle.getPage("Login");
>
>instead of
>
> IPage nextPage = ...;
>
>Just my 2 cents.
>
>Andy
>
>
>T.Mikov schrieb:
>
>
>>Out of curiosity, why is prefixing interfaces with "I" considered bad ?
>>It seems like a good thing to me, since an interface is different from a
>>class, after all.
>>
>>regards,
>>Tzvetan
>>
>>Erik Hatcher wrote:
>>
>>
>>
>>>For reference, here's what we're doing with Lucene.... there has been
>>>a slew of API changes since the last stable release (version 1.4.3).
>>>We've deprecated many API methods, but not broken any backwards
>>>compatibility. We've even copied the entire test suite (which is
>>>fairly robust) and kept one set of tests that deal with the now
>>>deprecated API and updated the official test suite to use the new
>>>API. This keeps us honest and prevents us from removing something
>>>just yet. The next release of Lucene will be version 1.9 that is
>>>backwards compatible with the old API deprecated. Once that is
>>>released, we will remove all the deprecated stuff and release a 2.0
>>>version. If you can compile with no deprecation warnings with 1.9 you
>>>will be fine to upgrade to 2.0.
>>>
>>> Erik
>>>
>>>
>>>
>>>On Apr 21, 2005, at 10:00 PM, Ben Eng wrote:
>>>
>>>
>>>
>>>>I like that idea. At least it gets us started down the path towards
>>>>the desired destination.
>>>>
>>>>Ben
>>>>
>>>>On Thu, Apr 21, 2005 at 09:33:52PM -0400, Erik Hatcher wrote:
>>>>
>>>>
>>>>
>>>>>Let's be pragmatic, though. It would be rude to simply remove things
>>>>>just to clean up naming and break things for no strong technical
>>>>>reason. I hate the I* names myself, as does Howard these days. An
>>>>>intermediate step would be to put extend those interfaces with names we
>>>>>like, deprecate the I* interfaces, and remove them in the subsequent
>>>>>release (or something like that).
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Actually, last time I checked in with the committers, all of the
>>>>>>I's in
>>>>>>the interfaces were being removed. In my opinion a good thing, reminds
>>>>>>me to much of my COM days and makes me twitch.
>>>>>>
>>>>>>
>>>>>> _____
>>>>>>
>>>>>>From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
>>>>>>Sent: Thursday, April 21, 2005 1:51 PM
>>>>>>To: tapestry-user@jakarta.apache.org
>>>>>>Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
>>>>>>
>>>>>>
>>>>>>
>>>>>>I would like "I" prefix to go in the interface name. As a user of
>>>>>>Tapestry, why should I care if RequestCycle is an interface or class
>>>>>>(implementation).
>>>>>>
>>>>>>
>>>>>>
>>>>>>Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
>>>>>>online
>>>>>>here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
>>>>>><http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Andy Pahne <a....@skaffen.de>.
I dislike the I in the interfaces, because if you follow the good
practice of programming against interfaces, you always have to deal with
this extra I. It's just more natural to code
Page nextPage = cycle.getPage("Login");
instead of
IPage nextPage = ...;
Just my 2 cents.
Andy
T.Mikov schrieb:
> Out of curiosity, why is prefixing interfaces with "I" considered bad ?
> It seems like a good thing to me, since an interface is different from a
> class, after all.
>
> regards,
> Tzvetan
>
> Erik Hatcher wrote:
>
>> For reference, here's what we're doing with Lucene.... there has been
>> a slew of API changes since the last stable release (version 1.4.3).
>> We've deprecated many API methods, but not broken any backwards
>> compatibility. We've even copied the entire test suite (which is
>> fairly robust) and kept one set of tests that deal with the now
>> deprecated API and updated the official test suite to use the new
>> API. This keeps us honest and prevents us from removing something
>> just yet. The next release of Lucene will be version 1.9 that is
>> backwards compatible with the old API deprecated. Once that is
>> released, we will remove all the deprecated stuff and release a 2.0
>> version. If you can compile with no deprecation warnings with 1.9 you
>> will be fine to upgrade to 2.0.
>>
>> Erik
>>
>>
>>
>> On Apr 21, 2005, at 10:00 PM, Ben Eng wrote:
>>
>>> I like that idea. At least it gets us started down the path towards
>>> the desired destination.
>>>
>>> Ben
>>>
>>> On Thu, Apr 21, 2005 at 09:33:52PM -0400, Erik Hatcher wrote:
>>>
>>>> Let's be pragmatic, though. It would be rude to simply remove things
>>>> just to clean up naming and break things for no strong technical
>>>> reason. I hate the I* names myself, as does Howard these days. An
>>>> intermediate step would be to put extend those interfaces with names we
>>>> like, deprecate the I* interfaces, and remove them in the subsequent
>>>> release (or something like that).
>>>>
>>>> Erik
>>>>
>>>>
>>>>
>>>> On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
>>>>
>>>>> Actually, last time I checked in with the committers, all of the
>>>>> I's in
>>>>> the interfaces were being removed. In my opinion a good thing, reminds
>>>>> me to much of my COM days and makes me twitch.
>>>>>
>>>>>
>>>>> _____
>>>>>
>>>>> From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
>>>>> Sent: Thursday, April 21, 2005 1:51 PM
>>>>> To: tapestry-user@jakarta.apache.org
>>>>> Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
>>>>>
>>>>>
>>>>>
>>>>> I would like "I" prefix to go in the interface name. As a user of
>>>>> Tapestry, why should I care if RequestCycle is an interface or class
>>>>> (implementation).
>>>>>
>>>>>
>>>>>
>>>>> Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
>>>>> online
>>>>> here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
>>>>> <http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by "T.Mikov" <tm...@gmail.com>.
Out of curiosity, why is prefixing interfaces with "I" considered bad ?
It seems like a good thing to me, since an interface is different from a
class, after all.
regards,
Tzvetan
Erik Hatcher wrote:
> For reference, here's what we're doing with Lucene.... there has been a
> slew of API changes since the last stable release (version 1.4.3).
> We've deprecated many API methods, but not broken any backwards
> compatibility. We've even copied the entire test suite (which is fairly
> robust) and kept one set of tests that deal with the now deprecated API
> and updated the official test suite to use the new API. This keeps us
> honest and prevents us from removing something just yet. The next
> release of Lucene will be version 1.9 that is backwards compatible with
> the old API deprecated. Once that is released, we will remove all the
> deprecated stuff and release a 2.0 version. If you can compile with no
> deprecation warnings with 1.9 you will be fine to upgrade to 2.0.
>
> Erik
>
>
>
> On Apr 21, 2005, at 10:00 PM, Ben Eng wrote:
>
>> I like that idea. At least it gets us started down the path towards
>> the desired destination.
>>
>> Ben
>>
>> On Thu, Apr 21, 2005 at 09:33:52PM -0400, Erik Hatcher wrote:
>>
>>> Let's be pragmatic, though. It would be rude to simply remove things
>>> just to clean up naming and break things for no strong technical
>>> reason. I hate the I* names myself, as does Howard these days. An
>>> intermediate step would be to put extend those interfaces with names we
>>> like, deprecate the I* interfaces, and remove them in the subsequent
>>> release (or something like that).
>>>
>>> Erik
>>>
>>>
>>>
>>> On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
>>>
>>>> Actually, last time I checked in with the committers, all of the I's in
>>>> the interfaces were being removed. In my opinion a good thing, reminds
>>>> me to much of my COM days and makes me twitch.
>>>>
>>>>
>>>> _____
>>>>
>>>> From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
>>>> Sent: Thursday, April 21, 2005 1:51 PM
>>>> To: tapestry-user@jakarta.apache.org
>>>> Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
>>>>
>>>>
>>>>
>>>> I would like "I" prefix to go in the interface name. As a user of
>>>> Tapestry, why should I care if RequestCycle is an interface or class
>>>> (implementation).
>>>>
>>>>
>>>>
>>>> Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
>>>> online
>>>> here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
>>>> <http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
For reference, here's what we're doing with Lucene.... there has been a
slew of API changes since the last stable release (version 1.4.3).
We've deprecated many API methods, but not broken any backwards
compatibility. We've even copied the entire test suite (which is
fairly robust) and kept one set of tests that deal with the now
deprecated API and updated the official test suite to use the new API.
This keeps us honest and prevents us from removing something just yet.
The next release of Lucene will be version 1.9 that is backwards
compatible with the old API deprecated. Once that is released, we will
remove all the deprecated stuff and release a 2.0 version. If you can
compile with no deprecation warnings with 1.9 you will be fine to
upgrade to 2.0.
Erik
On Apr 21, 2005, at 10:00 PM, Ben Eng wrote:
> I like that idea. At least it gets us started down the path towards
> the desired destination.
>
> Ben
>
> On Thu, Apr 21, 2005 at 09:33:52PM -0400, Erik Hatcher wrote:
>> Let's be pragmatic, though. It would be rude to simply remove things
>> just to clean up naming and break things for no strong technical
>> reason. I hate the I* names myself, as does Howard these days. An
>> intermediate step would be to put extend those interfaces with names
>> we
>> like, deprecate the I* interfaces, and remove them in the subsequent
>> release (or something like that).
>>
>> Erik
>>
>>
>>
>> On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
>>
>>> Actually, last time I checked in with the committers, all of the I's
>>> in
>>> the interfaces were being removed. In my opinion a good thing,
>>> reminds
>>> me to much of my COM days and makes me twitch.
>>>
>>>
>>> _____
>>>
>>> From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
>>> Sent: Thursday, April 21, 2005 1:51 PM
>>> To: tapestry-user@jakarta.apache.org
>>> Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
>>>
>>>
>>>
>>> I would like "I" prefix to go in the interface name. As a user of
>>> Tapestry, why should I care if RequestCycle is an interface or class
>>> (implementation).
>>>
>>>
>>>
>>> Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
>>> online
>>> here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
>>> <http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Ben Eng <be...@jetpen.com>.
I like that idea. At least it gets us started down the path towards
the desired destination.
Ben
On Thu, Apr 21, 2005 at 09:33:52PM -0400, Erik Hatcher wrote:
> Let's be pragmatic, though. It would be rude to simply remove things
> just to clean up naming and break things for no strong technical
> reason. I hate the I* names myself, as does Howard these days. An
> intermediate step would be to put extend those interfaces with names we
> like, deprecate the I* interfaces, and remove them in the subsequent
> release (or something like that).
>
> Erik
>
>
>
> On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
>
> >Actually, last time I checked in with the committers, all of the I's in
> >the interfaces were being removed. In my opinion a good thing, reminds
> >me to much of my COM days and makes me twitch.
> >
> >
> > _____
> >
> >From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
> >Sent: Thursday, April 21, 2005 1:51 PM
> >To: tapestry-user@jakarta.apache.org
> >Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
> >
> >
> >
> >I would like "I" prefix to go in the interface name. As a user of
> >Tapestry, why should I care if RequestCycle is an interface or class
> >(implementation).
> >
> >
> >
> >Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
> >online
> >here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
> ><http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Let's be pragmatic, though. It would be rude to simply remove things
just to clean up naming and break things for no strong technical
reason. I hate the I* names myself, as does Howard these days. An
intermediate step would be to put extend those interfaces with names we
like, deprecate the I* interfaces, and remove them in the subsequent
release (or something like that).
Erik
On Apr 21, 2005, at 5:03 PM, Hensley, Richard wrote:
> Actually, last time I checked in with the committers, all of the I's in
> the interfaces were being removed. In my opinion a good thing, reminds
> me to much of my COM days and makes me twitch.
>
>
> _____
>
> From: Tapestry Forum User [mailto:maillist@tapestryforums.com]
> Sent: Thursday, April 21, 2005 1:51 PM
> To: tapestry-user@jakarta.apache.org
> Subject: If we call it Tapestry 4.0, not 3.x, Maybe we would do much
>
>
>
> I would like "I" prefix to go in the interface name. As a user of
> Tapestry, why should I care if RequestCycle is an interface or class
> (implementation).
>
>
>
> Sent using Mail2Forum (http://www.mail2forum.com) Read this topic
> online
> here: http://www.tapestryforums.com/viewtopic.php?p=1549#1549
> <http://www.tapestryforums.com/viewtopic.php?p=1549#1549>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org