You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/02/27 04:03:36 UTC
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repo s
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
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repo s
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 26, 2003 at 11:03:36PM -0500, Greg Hudson wrote:
> 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.
>
>... snip ...
Well, I think we disagree on terminology here. I see strong/weak as what you
can do with a datum. Strong means you can't circumvent its type. I see
dynamic/static as when type information is established.
>...
> 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.
Right.
> (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.)
*nod*
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
language type safety
Posted by sam th <sa...@uchicago.edu>.
On Wed, 2003-02-26 at 22:03, Greg Hudson wrote:
> 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".
This isn't a type property, this is a property of Python integers that
means that their bit representation can't be interpreted as the bit
representation of something else (like an integer).
>
> "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.
I've only ever seen it used to mean "statically typed".
>
> 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.
This isn't really "weaker". This just means that foo is a syntactic
abbreviation for int. In languages with structural typing, these
abbreviations wouldn't be any more than different spellings, but in
languages with nominal typing, there is a choice as to whether they can
be used interchangably. C says yes, Ada no (apparently, I don't know
Ada).
>
> 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.
Again, this just means that Scheme has structural types. Of course,
Scheme is dynamically typed, which means that it is "weaker" than C in
this respect, but the difference you mention isn't why.
> 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.)
Actually, Java has much stronger typing than C++. You can still
reinterpert an int as a pointer in C++, which violates type safety.
Java just has the unfortunate property that their type system is
unsound, since Java says:
Array[5] of A <: Array[5] of B
when
A <: B
where <: means 'is a subtype of'. This implication is, sadly, false.
The original relationship is only true when A = B.
Java solves this by adding dynamic checks. Additionally, mixing types
in the vector is a sure sign that your type system is broken, since what
type does the resulting vector have?
[ Glad I'm taking this type systems course for a reason. ]
--
sam th <sa...@uchicago.edu>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org