java inet_aton,inet_aton java,java strong type,inet_aton in java,strong hash map,strong type weak type,weak declaration in c,haskell implicit cast,is java weakly type,java haskell type system, xml%%%java inet_aton - Re: Strong versus (weak

[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Strong versus (weak|runtime) typing


java inet_aton
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.