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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Date: 1997/02/09 Message-ID: #1/1 X-Deja-AN: 217511605 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <32E7E08A.3079@parcplace.com> <32E8BCE3.3029@calfp.com> <01bc0a1e$faed8ce0$c318b993@jarvisb> <5covaj$l0@boursy.news.erols.com> content-type: text/plain; charset=US-ASCII organization: Home's where my rucksack's mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-02-09T00:00:00+00:00 List-Id: >>> "feldmand" == Damon Feldman writes: >> I think it's a bit misleading to say that Smalltalk is dynamically >> typed versus Ada/C++/etc being statically typed. I mean, Smalltalk >> does not check the type of an object when passing it as a parameter feldmand> Statically typed means that types are *determined* at compile feldmand> time. Consider: class A { ... }; class B : A { ... }; class A a; class B b; class B *bp; bp = (randomNumber() > 0.5) ? &a : &b; Here there is no question that 'bp' has a static type constraint, and also no question that it is impossible statically to infer the type of object denoted by 'bp' after the assignment above. The rest of your arguments are consistent with the one above :-). feldmand> Dynamically typed means types are *determined* at runtime. Please give even a single example of runtime determination of types in any popular language. All popular languages have statically manifest variable types, and statically manifest constraints (if any) on variables; it's the type of the objects attached to a variable that may be only apparent at runtime. It would be interesting to be given an example of any popular (non-research) language in which the type of a variable can change dynamically, or even just its constraint can change dynamically. feldmand> Static type *checking* means checking done at compile time. feldmand> Dynamic type *checking* means checking at run time, I suppose. feldmand> "Checking" catches errors, "determining" types determines what feldmand> class a variable is (and therefore how it handles messages and feldmand> what data it has access to). In all popular languages all variables belong to the same ``class'' (which is usually, like in Smalltalk-80, not reified), and all have exactly the same operators; in particular in languages like Smalltalk-80 variables do not have access to any message, but only to the assignment (and dereferencing) operator. feldmand> To my knowledge all statically-typed languages do static type feldmand> checking. Since the programmer was forced to commit to fixed feldmand> types at compile time it would be dumb not to check for errors feldmand> in this cheap and easy-to-debug way. feldmand> But dynamically typed languages just generate errors rather feldmand> than explicitly do dynamic type-checking. (This is a bit of a feldmand> simplification, but that's the idea.) feldmand> So Smalltalk is dynamically typed because objects can get feldmand> different types at runtime depending on execution, I am curious to be told which version of ``Smalltalk'' you are talking about, because even beginners know that in classic versions like Smalltalk-80 it is absolutely impossible to do as you say. Once instantiated, the type of an object cannot be validly changed in Smalltalk-80 (nor in most of its successors/derivatives). feldmand> even though it is not type checked explicitly beyond feldmand> generating an error or automatically expanding collection feldmand> sizes, etc.