Well, you could try removing it and see what happens :) What declared type does getWorld() return? (check the documentation) - it's "World". Now, it just so happens that we know the world is actually a "Space", but the compiler isn't aware of that (or, to put it another way, it believes there is a possibility that the world might in fact not be a Space - which is true; because you could create another World subclass and place your object in that!). So, without the typecast, you'll get an error when you compile. So, "(Space) getWorld()" means, roughly speaking: call getWorld(), and even though the declared return type of getWorld() is "World", I know in this case that it will really return a "Space".

So if I understand correctly: The variable spaceWorld which has already been declared to be of the type Space.class, could possibly be assigned something *other* than an object of type Space.class (assuming another World subclass object existed)? (BTW, thanks for your help with my education ;-)

If it's declared to be of type "Space", then it can reference an object of type Space or any subclass of Space, but not any other subclass of World.

Since Space is a subclass of World, it would follow that were that same line of code to read: then it should compile and spaceWorld should have all the attributes and methods provided by the World.class to the Space.class object returned by getWorld() but with the Space.class extensions amputated, no?

Well, yes, but you don't need the cast in that case; this does the same: "getWorld()" already returns World, so there is no need for casting. As you're suggesting, you couldn't then call methods that are specific to Space.

So then typecasting an object's assignment can never yield greater capacity than the object's declared class provides (hence typecasting as a descendant class is meaningless), and the default type is the ancestor, which would seem to militate against the declaration. I guess I still don't see the rationale for this behaviour. Is this a java characteristic or peculiar to Greenfoot? (I must confess to being a Borland Pascal aficionado, which may help to explain some of my predilections) Thank you for any insight you may be willing to share as I attempt to orient my program objectively.

Can you give an example (i.e. code) of what you mean? I'm not sure what you mean by this either, sorry. It's a characteristic of Java. The language you code in when you use Greenfoot is Java; no more, no less.

An example of futile typecasting as a descendant class (extensions are lost): And an example of the default (no typecast) returning the ancestor (World),: instead of returning the declared subclass Space, which the object is already declared to be. So it would seem there *must* be some advantage to having the compiler ignore the declaration in determining which class/subclass of World to return, necessitating the seemingly redundant typecast of getWorld(), which at present just escapes me.

Ok, you're correct that in this case the cast is pointless. (It is still not completely meaningless - the cast will be checked at runtime, and an exception will be thrown getWorld() returns something that is not a Space; but this usage is uncommon). The "getWorld()" method call results in an expression of type World, because that is what it is declared to return. This particular example you have given would not compile, because the compiler sees that you have tried to assign something which (as far as it is concerned) could be an instance of any subclass of World, to a variable "spaceWorld" of type Space, which may not be correct. The error is warning you of this. The typecast is your way of informing the compiler that you are aware of the mismatch and you know what you are doing. The advantage is that the compiler is able to diagnose and prevent a certain class of error - accidentally assigning an object reference to a variable of the wrong type.