> It is not about falling back on generic declarartion, it is about > how such object will be treated. Diez seems to think that > strongly-typed language can only deal with generic declarations > by using something that allows circumventing the type system.
No, I don't - now it's you who makes assumptions about what I think. ML and other FPs show that genericity can be done without circumvening. Templates and generics in C++ partially do so. > > > In other words, you want Python to be strongly-typed, but sometimes you > > want to allow a reference to be to any object whatsoever. In which case > > you can't possibly do any sensible type-checking on it, so this new > > Python+ or whatever you want to call it will suffer from the same > > shortcomings that C++ and java do, which is to say type checking can't > > possibly do anything useful when the acceptable type of a reference is > > specified as ANY. > > And you are wrong. The problem with the C void* construct (I'm not that > familiar with java) is that all type information is lost. When you > use such a parameter in a function you have no idea what you are > working with. You don't know JAVA - I do. And nobody said that it lost that type-information. It doesn't. Still, errors occur - namely ClassCastEcxeptions. That indicates that going back and forth via ANY doesn't necessarily lose any type information, but the capability of today's type-systems to keep that information across such a transition. This won't work: Object foo = A(); B bar = (B) foo; And please, pretty please don't argue with the simplicity of that example - think of a bazillion statements between these two, possibly done with run-time-instantiated classes that weren't known at compile-time. > But that doesn't need to be if you have a typesystem with an ANY type. > Such a type declaration would mean that object of any type could be > used here. However that doesn't imply that the type information > of the actual objects used, has to be lost. That type information > may still be available and usefull for further type checking. JAVA has that. > That you and Diez can only think about C, C++ or java constructs > when I mention an ANY type, is your limitation. It doesn't > need to be the limitation of a specific type system. Again: where are the specifics of this system? In your head? Tell us the gory detail, please. Diez -- http://mail.python.org/mailman/listinfo/python-list
