From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,b87849933931bc93
X-Google-Attributes: gidfac41,public
X-Google-Thread: 1108a1,b87849933931bc93
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,b87849933931bc93
X-Google-Attributes: gid103376,public
X-Google-Thread: 114809,b87849933931bc93
X-Google-Attributes: gid114809,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Static vs. Dynamic typing again (was Re: OO, C++,
 and something much better!)
Date: 1997/01/26
Message-ID: <E4n2rn.n4@world.std.com>#1/1
X-Deja-AN: 212408113
references: <JSA.97Jan16141937@alexandria> <32E7BB32.6A9D@calfp.com>
 <32E85588.1978@parcplace.com> <32ec94c5.12380906@news.ipass.net>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object
Date: 1997-01-26T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <32ec94c5.12380906@news.ipass.net>,
Paul Perkins <paul.perkins@pobox.com> wrote:
>Another reason to think that some kind of declarative type feature
>could be useful in Smalltalk is that good Smalltalk programmers
>typically use naming conventions and sometimes even comments to
>indicate what kinds of values are expected to be bound to each
>variable. The idea of formalizing this just enough so that the
>information is available to automated tools is appealing to me.

Indeed.  The Smalltalk programmer writes

    grindOn: aString and: anotherString

whereas the Ada programmer writes

    procedure Grind_On(X, Y: String);

Obviously both programmers think its useful to know what type is
expected for a formal parameter.  The latter has the advantage that it
can't accidentally be incorrect information.

Note that this has nothing to do with static vs. dynamic type checking
-- Smalltalk doesn't check that aString and anotherString are indeed
Strings -- it doesn't check statically *or* dynamically.

- Bob