Re: Style guide (2nd update)
On Sunday 01 December 2002 22:26, Oleg Tkachenko wrote: >. . . > J.Pietschmann wrote: > > I think > > we should leverage "final" more often in FOP. > > At http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide we've > got +2 vs -2 on this point, so taking into acount your opinion it's +3 > vs -2 now. I think the +2 vs -2 that you mention refer to "declaring variables in the inner scope", not precisely to "using final or not". This thing about final is really minor IMHO, I think it's a good practice and should be mentioned as such, but I wouldn't make any checks on it. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
J.Pietschmann wrote: There is a lot of literature about when and why using C++ const is an advantage and when not, a large part of this is probably applicable to Java final. I think we should leverage "final" more often in FOP. At http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide we've got +2 vs -2 on this point, so taking into acount your opinion it's +3 vs -2 now. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
Rhett Aultman wrote: > It's my understanding that, for certain object types, the compiler can use > "final" designation as a flag for further optimizations and so it actually > might be a wise idea to do. If nothing else, I remember reading an interview > with James Gosling on "object mutability", a compiler optimization whereby a > final object can be decomposed into certain constituents (since it will never > be altered). > > Personally, I just don't use final designations in the way it's shown because > it doesn't occur to me that it's important. ;) Cocoon is full of "final", basically the same as the C++ use of "const", partly because it allows *all* compilers to do important optimisations, and partly because this let the compiler detect quite a few thinkos and some design flaws. For example, declaring method parameters as final disallows assignments to them, which may force the use of more localized variables, thereby often enhancing maintainability, helping dumb compilers to compile better code and decreasing the compile time for the cleveer compilers which can do proper flow analysis by itself. Another aspect is that it helps in detecting traps like if the parameter is named the same as an instance variable and someone thought he's assigning the instance variable instead of the parameter. There is a lot of literature about when and why using C++ const is an advantage and when not, a large part of this is probably applicable to Java final. I think we should leverage "final" more often in FOP. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Style guide (2nd update)
It's my understanding that, for certain object types, the compiler can use "final" designation as a flag for further optimizations and so it actually might be a wise idea to do. If nothing else, I remember reading an interview with James Gosling on "object mutability", a compiler optimization whereby a final object can be decomposed into certain constituents (since it will never be altered). Personally, I just don't use final designations in the way it's shown because it doesn't occur to me that it's important. ;) -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 11:42 AM To: [EMAIL PROTECTED] Subject: Re: Style guide (2nd update) On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote: >. . . > final String myString = (String)myListIterator.next(); >. . . > How do you think, is this final specifier only a style oriented or it have > some performance benefit also? I don't know about performance, but I use it all the time anyway as it makes intentions clearer and can save the day by preventing someone from messing up with the variable value. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:31, Oleg Tkachenko wrote: >. . . > final String myString = (String)myListIterator.next(); >. . . > How do you think, is this final specifier only a style oriented or it have > some performance benefit also? I don't know about performance, but I use it all the time anyway as it makes intentions clearer and can save the day by preventing someone from messing up with the variable value. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On Thursday 21 November 2002 17:16, Jeremias Maerki wrote: >. . . > The MUST part is very small and establishes some hard rules. I'll try to > do the final layout in XML in a way that takes this into consideration. ok, cool! >. . . > By the way, due to common desire I added a few lines on exception > handling and a few other items that I found were agreed upon in recent > discussion. I added note 4 to propose a different/additional way of saying that exceptions are important. I'd put this stuff about exceptions as a subsection in the MUSTS, this so much more important than brace placement ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
Hello! btw, I have a q about avalon's pattern: while( myListIterator.hasNext() ) { final String myString = (String)myListIterator.next(); } How do you think, is this final specifier only a style oriented or it have some performance benefit also? -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (2nd update)
On 20.11.2002 18:05:33 Bertrand Delacretaz wrote: > I voted -1 on most TBD stuff, braces and spaces are not really important IMHO > and I think it's good that the style guide stays as small as possible. Also my opinion, though I think some good advice and best practices are not bad. We've had discussions about certain points every now and then. That's why I've split the Java conventions into a MUST and a SHOULD part. The MUST part is very small and establishes some hard rules. I'll try to do the final layout in XML in a way that takes this into consideration. By the way, due to common desire I added a few lines on exception handling and a few other items that I found were agreed upon in recent discussion. You can still put -1s where you don't like something I've done. As soon as Jörg is back (because he started the discussion in August) I'd like to hold a formal voting process for accepting the style guide. When all points are resolved I'll transform the Wiki page to XML. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]