I agree. The order of definitions for classes and -global scope- functions shouldn't matter yet it does with regard to extending. It will also muck up in some cases where the parser incorrectly misses  that functions refer to things not yet instantiated, something that I suspect is a separate but closely related issue that should instead yield a warning from the parser. IMHO this is a bug as the specs don't ever refer to this order mattering at all, though I could see how we might demand placing "class bar extends foo" below "class foo". Apparently this bug can also affect the type-system in how it deals with the type of returned objects when those extend other types. When it doesn't you'll find the objects don't have the member functions you added when extending and will get a error for that.

We may by now wonder whether there is anything that *doesn't* affect the type of returned objects of a type that extends another ;-). Your workaround is what I suggest (and use) as well and so far that seems stable to me. You might be able to get around this by casting up and down for a bit but I tend to reserve that for emergencies as typically it leads to very fragile code. It also tends to lead to headaches and cursing for me.

So; yes, a bug. Or more like two that now turn out to interact. Let's hope they are not each other's type.

Yours,

Kas.