[98] in java-interest
Implict type conversions and strings
daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Fri May 19 14:11:36 1995
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
To: java-interest@java.Eng.Sun.COM
Date: Fri, 19 May 1995 18:27:02 +1000 (EST)
My compiler is now at the point where I'm analyzing ASTs and
annotating them with type information. As part of this it does
implicit type promotion and binding method calls to actual methods,
and implicit conversions to Strings.
Promotion:
The Java spec doesn't go into detail about how types are promoted,
which I normally take to mean "Look at ISO C". However, in this
case I think the mechanism used for method call resolution generalizes
to this. For example, if I have:
t1 + t2
Assuming t1 and t2 are both simple arithmetic types: If they're
the same type, then the add will evaluate to the same type Otherwise,
it looks up the conversion cost for t1->t2 and t2->t1 and compares
them. If the former is cheaper, the overall type will be t2, and
t1 will be implicitly cast to t2. Otherwise the converse happens.
This is not the same as the ISO C rules, which specify a rather
complex path between two types which may be more than one hop,
but is quite elegant: it always promotes so there's no information
loss, and as far as I can tell always does the right thing. Of
course, this is all because of the good design of the type conversion
cost table.
Is this what javac does? If not, will the results be the same?
Strings:
If the operation is '+', and one of the arguments is String, then
it converts the other one to string, assuming it isn't already.
If the non-String argument is a composite type it calls it's toString()
method (if present). If it's a simple type it calls String.valueOf(t),
using overloading to choose the right version of valueOf() to call.
I assume this is what javac does, but I haven't checked.
However, if one or both arguments to '+' are composite and neither
is a string, there are two ways the compiler could cope with this.
One is to complain. The other is to convert both arguments to
Strings and concatenate them. Not necessarily what you want, but
certainly a predicable behaviour.
Does Java require one of the arguments to '+' to be explicitly a
String before converting the other one to a String, or can a compiler
spontaneously convert both to Strings?
Similarly, if matching method arguments, can a compiler convert a
non-string argument to a String if that would be the best match
(with some appropriate cost for converting to a String)?
And what about "String x = 2;"? When a type on the right of an
assignment is coerced to the type of the left side, can stringifying
be one of the ways this can happen?
The underlying question is "how does implicit String conversion
interact with the other implicit type conversions: type promotion
and type widening?" Type promotion clearly only applies to simple
types, and similarly widening only applies to composite types. But
String conversion can apply to both and bridge the gap between
them. I'm finding it hard to get a clear mental model of how
stringifying fits in, so I can implement it. Of course the Java
spec could just explicitly list where the compiler might implicitly
convert things to Strings, but it would be much more elegant if it
were just the expression of a simple rule which could be appied
whereever necessary.
The only reason that stringifying isn't much more complex and
ambigious is because String is final, and therefore can't have any
derived classes. I think that's a shame, since a basic, powerful
type like String is just ripe for specialisation by other types
based on it. However, the current version of Java gives this up
in favour of a syntactially simple but conceptually muddled mechanism
which doesn't really allow String to be first class composite type.
It seems much cleaner to have just two mechanisms and fold String
conversion into type widening, with some syntactic sugar to save
typing some method calls. A java.lang.Stringable interface which
objects can implement seems like an interesting approach to doing
such a unification.
Note that I'm writing this from the point of view of someone trying
to write a Java compiler. I haven't really written a whole lot of
Java code, so perhaps the current mechanism is fine from a programmer's
point of view, and everything works as expected all the time.
Perhaps.
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
