Path: utzoo!attcan!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <1990Oct4.181822.22800@odi.com> Date: 4 Oct 90 18:18:22 GMT References: <0yw10qr@Unify.Com> <411@eiffel.UUCP> <736@tetrauk.UUCP> <1990Sep25.135145.3460@kth.se> <3832@osc.COM> <3851@m5.COM> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 59 In-Reply-To: tma@m5.COM's message of 3 Oct 90 01:14:48 GMT In article <3851@m5.COM> tma@m5.COM (Tim Atkins) writes: I take a bit of exception to C++ in this context. Dynamic binding means that that binding is done a run-time based on the run-time type of the receiver and the message sent. C++ emphatically does not support this. Instead it uses static type information to calculate the offset relative to a type specific pointer location within the receiver where the function may be found. There is no run-time lookup at all except to simply do the simple array reference. It depends at what level of abstraction you consider. At the level of abstraction of C++ semantics, as defined by the C++ Language Reference Manual: when you invoke a virtual function member, the function that gets called is determined by the type (class) of the object that the function member is invoked on. This is true whether it's implemented by calculating offsets, looking up in hash tables, or whatever. If you ignore the question of how it's implemented, it certainly does bind (that is, bind a particular function name to a specific virtual function member) at runtime. At the level of abstraction of the implementation, you say "There is no run-time lookup at all except to simply do the simple array reference." Another way to say the same thing is "There is a runtime lookup, which is implemented using a simple array reference." No matter how you describe it, it's certainly determining at runtime what function to call. >Strong typing is especially valuable for programming-in-the-large where the >edit-compile-debug cycle is especially tedious. All other things being >equal (they're not), ``sooner'' error detection is better than ``later''. Ah, but I would contend that static typing environments necessitate to a large degree just the type of ills you represent them as curing. It is much more difficult to create an incremental, highly interactive develop- ment environment for a statically typed language. One also has commonly more code to debug as the re-useability is a bit more constrained by many of the static typing models. In a dynamically typed interactive environment I believe I will catch errors much faster because changes are incremental and because I tend to test much more when I don't have to "edit-compile-link" a new program just to test a new feature. - Tim Atkins As someone who has had very extensive experience using both kinds of environment (Genera/Symbolics Common Lisp and SunOS/C++), I think I can reliably report that there is a lot of truth in both of these statements. Static typing (typed variables) does catch more errors at compile time, and it's easier to fix them when they're caught at compile time, and if they're caught at compile time then you hear about them even if they are in paths of the code that are very rarely executed. On the other hand, interactive incremental environments are really great, and I sorely miss them in C++. However, the two things are not mutually incompatible, although I think I agree that it's not easy to put them together. I recommend that anybody interested in this look into Sabre C, which is a real incremental interactive environment for C. Rumor has it that they are working on a C++ version, which I'll be looking forward to.