Re: Strong versus (weak|runtime) typing
On Thursday 13 February 2003 10:01, Sean McGrath wrote: > It always amuses me to see developers using languages like Java spend so > much time typing their variables/objects at declare time, only to spend the > same amount of time > telling the system what type they are when they come out of hash tables > and so on. That's because Java's type system isn't expressive enough (yet). With parametric types, you'll be able to say "Hash map of strings to integers" and it will then have this type information. What you're seeing is that Java collection classes are *weakly* typed, that's all. So they have to make a guarantee to the compiler that they're willing to take responsibility for the typing when it comes back into the strongly typed world. Even "weakly typed" languages have this; when you call a function, say, to open a socket, it is up to you to feed it an IP address and a port number, two integers. If you give it an image object instead, you get a runtime error. Strong typing is just about providing the *abaility* to move those type requirements back along the data flow chain; if the value you pass to the socket open function comes from inet_aton, and inet_aton is declared to return an IPAddress object, then the compiler can complain at compile time of possible errors. However, thanks to the halting problem and Godel's theorem, no type system can do *everything*; even if you do create a type system that knows about parametric types, and knows about units (this isn't just an integer, it's an integer in *cubic seconds per square volt*), and so on it'll still have to, at some point, just trust the developer with a cast and signal an error at run time. For example, it's impossible to statically check types used in environments outside of the application, for example, on the other end of a network connection. But that doesn't make static typing bad; I think you're rebelling more against implementations than the concept itself. 1) Some type systems are nicely elegant and seem able to capture the programmers intentions without getting in the way too much, and are easy to escape when necessary. 2) Some type systems are extensible, allowing you to include your own arbitrary code to define what "type compatability" means. This ranges from being able to define implicit cast functions to being able to implement full OO in user libraries. 3) Static typing does not have to mean declaring the type of every single declaration. Type inferencing systems are statically typed, but declaring the types is optional; eg, Haskell and ML. > regards, > Sean ABS -- A city is like a large, complex, rabbit - ARP
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format