Etienne Gagnon wrote:
Hi Dalibor,
I would drop h) altogether.
O.K.,o.k., so be it. ;)
Rationale: while a "naive" Java compiler would produce a series of iload
instructions, for reusing a local variable, an optimizing compiler or a jit
would completely remove this. So, yes, the code that reuse a local could be
a little slower on a interpreter (I am sure that on sablevm this would be
negligible as iload is a very cheap operation), but good software engineering
is the goal here.
Here's the latest version:
a) toString output should begin with the name of the class
Rationale: When a field is declared as having an interface type, or a non-final class, it is useful to know the exact type of the instance.
b) the rest of the string should be braced in '[' and ']'
Rationale: Visual separation makes it easier to separate the output string into its type information and information about the state of the particular instance.
c) different instances should have different string representations
Rationale: If two instances are not equal, then their string represenation should reflect that. The contents of all fields used in equals() should be part of the string representation of an instance.
d) fields that are used in the string representation must be named
Rationale: Explicitely naming fields removes ambiguities when a class contains several fields of the same type.
e) always use a StringBuffer
Rationale: While most Java compilers can optimize string concatenation by using string buffers automatically, that only works efficiently as long as the string representation can be generated within a single expression. If that's not the case, for example when iterating over a collection, most Java compilers create unnecessary temporary objects. Using a StringBuffer ensures that toString() works efficiently.
f) don't use toString() on non-primitive fields
Rationale: Calling toString() can fail if a field's instance in null, resulting in a NullPointerException being thrown inside toString(). Since toString() is usually used to provide debugging information, it must not fail. Using StringBuffer.append(Object) handles null automatically. So simply use StringBuffer's append method for "field_name=" and the field instance.
g) don't write special code to handle fields being null
Rationale: follows from f).
Example code:
public class Test{
private String field_1;
private int field_2; public String toString() {
StringBuffer sb = new StringBuffer("Test[field_1=")); sb.append(field_1);
sb.append(",field_2=");
sb.append(field_2);
sb.append(']');return sb.toString(); } }
comments are welcome, as usual.
cheers, dalibor topic
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
