[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repo s

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-02-27 05:03:36 CET

On Wed, 2003-02-26 at 21:53, Greg Stein wrote:
> Not sure that I understand... yes, Python *does* have strong types. Unlike
> C, if you're given an integer, you can't treat it as a string. That is
> "strong".

"Strong typing" isn't a precisely defined term. It usually refers to
static type checking, but can refer to many other facets of a language's
type system.

Languages like C have "stronger" typing than languages like Python
because they check types statically at compile time, rather than at run
time.

Languages like C have "weaker" typing than languages like Ada because if
you "typedef int foo;", int and foo are considered compatible types; you
can accidentally pass an int instead of a foo and not notice.

Languages like C have "stronger" typing than languages like Scheme
because in C, two different struct declarations are never compatible
types even if they have the same members, whereas in Scheme, two types
represented as a list of three atoms are quite compatible.

Languages like Java have "weaker" type checking that languages like C++
because they don't have templates; you can use the Object type to create
a generic container class, but you lose static type checking on the
contents of the vector. (Of course, you gain the ability to mix the
types of what goes into the vector.)

It's true that it's a little weird seeing a hash table used to transmit
information from one C function to another. But it's not unheard of; X
toolkit resources, PAM data registrations, and gtk object data
registrations are all precedents.

(We do have an unpleasant tendency in Subversion to use void * in
functions which aren't actually polymorphic. But usually someone
catches it and it gets fixed.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 05:15:56 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.