>>66
I agree with you when people use types that promise that the type must store certain fields within itself. There is no way to know that the data types will always contain those fields in the future. Some implementations of the data type might delagate storage of the fields to other data types, and still be able to provide the functionality required for the using code. The only difference is that it might take a different size in memory, or it might require the usage of virtual functions to invoke the interface it provides. So this is a big deal in a language like seeples, but it should never matter in languages like Java. In an environment like that, all methods are virtual and it isn't possible to explicitly allocate an object inside of an array, or on the stack, or in a byte buffer, although you can use encodings and then instantiate the object from the encoding.
But I think static typing of the interfaces is useful for keeping track of what is going on, and what things. By looking at the interface an object implemnts, and looking up the documentation of the interface, you then know what you can do with this object. It is easy to lose track of what is what and what you can do with what in a large project using a dynamically typed langauge, and if there are no comments that indicate what the types actually are.