[104] in java-interest
Re: Implict type conversions and strings
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Fri May 19 16:37:51 1995
Date: Fri, 19 May 1995 11:37:55 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Hi Jeremy,
> 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.
The result of operations on integer types smaller than int is always
and int. If types with more precision are involved the result is always
of the type with the highest precision. The rules should be the same as
in ANSI-C.
> Is this what javac does? If not, will the results be the same?
No and No.
> 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.
If either of the two arguments to '+' is an object it will result in
string concatenation. It will then call String.valueOf() on each
argument that is not already a String.
> 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?
As long as they are not both numbers, the compiler will assume
string concatenation is the right thing.
> 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)?
No. The compiler never does implicit conversions to strings other
then for the + operator.
> 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?
No. The compiler never does implicit conversions to strings other
then for the + operator.
> 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.
The only special hack in the compiler is the string concatenation
operator. There are no other implicit conversions (except those on
numeric types). Class String is final so that the compiler can do
optimizations that would otherwise not be possible.
> 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.
I've found the string concatenation operator very useful. I've not run
into an places where it is confusing. I always put parenthesis around
expressions to avoid confusion:
String str = "a + b = " + (a + b);
Have fun,
Arthur van Hoff (avh@eng.sun.com)
http://java.sun.com/people/avh/
Sun Microsystems Inc, M/S UPAL02-301,
100 Hamilton Avenue, Palo Alto CA 94301, USA
Tel: +1 415 473 7242, Fax: +1 415 473 7104
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
