Re: Replies to Upcasting vs downcasting.

On 2009-02-18 23:49:58 -0500, rvclayton@xxxxxxx (R. Clayton) said:

Thanks everyone for the responses.

I appreciate that you've taken the time to produce a single, cohesive reply, but you might consider posting it in the original thread. The References: header can hold many message-IDs; most newsreaders only use the first for threading, but at least your post would appear in the same thread.

Stefan Ram:

int i =( int )doubleValue;

I take this example to be a conversion cast, although I can see how it
could be considered a downcast. My question involved casting with respect
to reference types, where there's no bit-munging conversion going on. I
was sloppy in implicitly assuming that downcasting involves references.

The Java language specification uses the terms "narrowing conversion" and "widening conversion" to encompass both reference conversions (which you actually asked about) and non-reference conversions (which Stefan illustrated). In summary, widening conversions are those for which, if the original type can represent a given value, then the target type can also represent that value.

All ints, for example, are also representable as doubles.

The conversion is called "widening" because the target type is "wider" - allows at least all, and probably more than all, of the values of the source type. Narrowing conversions are the other way around: some (or even most) of the source type's values may not be representable in the target type. Java always requires a cast for a narrowing conversion.

Not all doubles are representable as ints (only a small subset are); there are conversion rules for the remaining values, but you must affirm that you want to use them by writing a cast, as they discard information.

Mike Schilling:

Requiring the explicit cast 1. Ensures that the author of the code realizes
that he's written something that, on the surface, at least, might
fail. 2. Alerts readers of the code of the same thing.

I suppose, but an upcasting assignment can fail too (albeit always at
compile time) if the right-hand side type can't possibly be a descendant
of the left-hand side type. Shouldn't this logic dictate an explicit
upcast too?

Reference conversions do not require a cast if and only if the type of the target reference is a supertype of the type of the source expression, or if they are the same type. In the case you describe (assigning a reference of type B from an expression of type A, where the only common type is Object) you must include a cast to B.

Arne Vajhøj:

The last code is a hack that violates good OOP and can potentially
result in a ClassCastException.

You should be happy that they allow the last one !

I'm certainly willing to believe it's bad programming practice, or at least
a code smell. I'm thinking, however, that without up- and downcasting to
and from Objects it wouldn't be possible to implement general-purpose
containers.

Semi. The places where explicit casts are actually necessary are pretty limited now that Java has generics, which are in part a way to have the compiler prove the correctness of the casts to and from Object (or another limiting type).

There are some limitations around arrays, but there, casts allow the programmer to express that he's sure of the correctness when the compiler can't prove it.

Joshua Cranmer:

If you're asking, why require a cast even though it can't prove it,
the simplest reason is that it would be an unsafe cast.

It would be unsafe without the cast, you mean? That's not clear to me. In
the absence of a compile-time proof that the assignment is type correct the
matter is deferred until run-time, but in either case the cast doesn't seem
to be adding any useful information.

The cast is an acknowledgement from the programmer that the source expression is of a type that admits values that may not be accepted by the target reference. It doesn't matter if the actual value is provably acceptable by the target reference at compile time, only that the type of the source expression is not a subset of the type of the target reference.

Daniel Pitts:

The downcast is an acknowledgment by the programmer that they are sure that
the dynamic type is assignable to the static type. It forces the programmer
to carefully consider if this is indeed true.

Except that downcasting is always required, independent of the programmer's
ability to prove the type correctness of the assignment.

A thought about program structure: you knew when the object was created what types it was assignable to, and you know as a programmer what types of references you'll need to assign it to. Rather than casting, which is an out-of-band channel that can't be checked, don't lose track of the type in the first place within the program. Generics can help a lot with this.

Roedy Green:

http://mindprod.com/jgloss/cast.html

But I don't think that the downcast "assures Java that the dogRef pointer
really points to a Dalmatian.". The run-time check does that in the
absence of successful compile-time type analysis (for which the downcast is
unneeded, as far as I can tell). I was pleased, however, that the page
considers the (int) example above a conversion cast too.

"Assures" is not "ensures". An assurance is a declaration that you really know what you're doing, which Java will take at face value. Java's type rules, without casts, ensure the correctness of all conversions, at the expense of some bureaucratic work on the programmer's part.

Michael Jung:

In this case it can, but in some expressions an explicit downcast is
needed, e. g.: inherit((Child)p);

Assuming inherit() is a method, the formal parameter has a declared type,
which the compiler knows.

There may be two inherit(...) methods with compatible signatures:

void inherit (Parent)
void inherit (Child)

In the case where you have a reference of type Parent pointing to an object of type Child, the only way to directly invoke the (Child) overload is to create an expression of type Child - which you can do by casting the reference. There are patterns for doing this without casts, but they're a little fiddly (Visitor in particular tends to expose the entire type hierarchy through either the visitor or the visitee's interface).

-o

.

Relevant Pages

  • Re: Anders Hejlsberg comment on immutable objects
    ... >>explicit interface implementation exists is so an interface name can ... I wouldn't cast to an ... >>Improper conversion sounds like a good description, ... > variable as a sort of implicit reference, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Arghhh...strict, but not strict enough
    ... That's not what happens with CType. ... convert and cast as that is possible instead. ... output parametes are reference and value types or vice versa. ... A conversion implies that the original data is transformed into something ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >>explicit interface implementation exists is so an interface name can ... I wouldn't cast to an ... > variable as a sort of implicit reference, ... readonly const MyStruct myInstance. ...
    (microsoft.public.dotnet.languages.csharp)
  • Replies to Upcasting vs downcasting.
    ... could be considered a downcast. ... Requiring the explicit cast 1. ... but an upcasting assignment can fail too (albeit always at ... Java answers "Okay, boss, whatever you say (but I'll double-check when the ...
    (comp.lang.java.programmer)
  • Re: Terminology : casting/conversion
    ... Is this an "explicit" cast? ... conversion even if the type of the expression is the ... Here are p & p2 are pointers but the compiler "implicitly" converts ... this parse tree is almost unconnected to the ...
    (comp.lang.c)
Loading