Re: Style guide (2nd update)

2002-12-02 Thread Bertrand Delacretaz
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)

2002-12-01 Thread J.Pietschmann
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)

2002-12-01 Thread Oleg Tkachenko
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)

2002-11-21 Thread Jeremias Maerki

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]




Re: Style guide (2nd update)

2002-11-21 Thread Oleg Tkachenko
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)

2002-11-21 Thread Bertrand Delacretaz
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)

2002-11-21 Thread Bertrand Delacretaz
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)

2002-11-21 Thread Rhett Aultman
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]