Salut Etienne,
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
address@hidden
http://mail.gnu.org/mailman/listinfo/classpath