kdmoen@watcgl.UUCP (01/26/87)
In article <6565@alice.uUCp> ark@alice.UUCP writes: >In article <672@unc.unc.UUCP>, rentsch@unc.UUCP writes: >> Dynamic binding yields considerable advantages over Simula, >> including more polymorphic procedures and incremental compilation. >> (Those of you out there who have used Smalltalk and/or Lisp systems >> know what I'm talking about.) Basically, the only reason *not* to >> have dynamic binding is the belief that "it costs too much". > >Not so. Another reason to avoid dynamic binding is that doing so >makes it easier to catch certain programming errors early on. >The earlier an error is caught, the less damage it does. Two different concepts are being confused here. Smalltalk has Dynamic Binding because methods are bound to messages at run time. Smalltalk has Dynamic Type Checking because type errors (ie, 'message not understood') are detected at run time. I agree that dynamic type checking is a problem. I had an opportunity to play with Alan Bornings "ThingLab" and Randy Smiths "Alternate Reality Kit". These are both large applications written in Smalltalk. I was able to cause both programs to seize up with "message not understood" errors just by playing around. Although Smalltalk is great for rapid prototyping, it isn't suitable for programming large, *robust* applications, because you can never be sure that you haven't found all the type errors. However, there is no reason why a language could not support static type checking and dynamic binding. For example, one could define a statically typed variant of Smalltalk in which a 'type' specifies the set of messages understood by an object. We still have dynamic binding (and polymorphism), because two objects that accept the same message protocol are interchangeable at runtime, even if they have different implementations. But static type checking ensures that all 'message not understood' errors are detected at compile time. -- Doug Moen (watmath!watcgl!kdmoen) University of Waterloo Computer Graphics Lab
crowl@rochester.UUCP (01/26/87)
In article <459@watcgl.UUCP> kdmoen@watcgl.UUCP (Doug Moen) writes: >However, there is no reason why a language could not support static >type checking and dynamic binding. For example, one could define >a statically typed variant of Smalltalk in which a 'type' specifies >the set of messages understood by an object. We still have dynamic >binding (and polymorphism), because two objects that accept the same >message protocol are interchangeable at runtime, even if they have >different implementations. But static type checking ensures that all >'message not understood' errors are detected at compile time. Some references on systems that implement static type checking with dynamic binding to implementations: Andrew Black; Norman Hutchinson; Eric Jul; Henry Levy; "Object Structure in the Emerald System" ACM SIGPLAN Notices 21(11), 78-86; November 1986 Craig Schaffert; Topher Cooper; Bruce Bullis; Mike Kilian; Carrie Wilpolt; "An Introduction to Trellis/Owl"; ACM SIGPLAN Notices 21(11), 9-16; November 1986 -- Lawrence Crowl 716-275-5766 University of Rochester crowl@rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627
lsr@apple.UUCP (01/27/87)
In article <24179@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >Some references on systems that implement static type checking with >dynamic binding to implementations: > In addition: Larry Tesler; "Object Pascal Report" published in Structured Language World Volume 9, Number 3. Object Pascal is an extension of Pascal that supports definition of object types, inheritance, method calls. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
lsr@apple.UUCP (01/27/87)
In article <459@watcgl.UUCP> kdmoen@watcgl.UUCP (Doug Moen) writes: >I agree that dynamic type checking is a problem. I had an opportunity >to play with Alan Bornings "ThingLab" and Randy Smiths "Alternate Reality Kit". >These are both large applications written in Smalltalk. >I was able to cause both programs to seize up with "message not understood" >errors just by playing around. Although Smalltalk is great for rapid >prototyping, it isn't suitable for programming large, *robust* applications, >because you can never be sure that you haven't found all the type errors. > I am not sure if this is valid. Aren't Thinglab and ARK just research projects and not finished applications? There are a few commercial applicatiosn written in Smalltalk (e.g., the Humble expert system from Xerox). It would be more meaningful to look at one of these and see how reliable it is. >However, there is no reason why a language could not support static >type checking and dynamic binding. Agreed. Object Pascal does this. You still have to do sufficient testing on your program; I don't think object-oriented programs are any worse in this respect. Also, in Smalltalk you can implement messageNotUnderstood and try to correct the problem. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
rgatkinson@watmum.UUCP (01/28/87)
In article <412@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <459@watcgl.UUCP> kdmoen@watcgl.UUCP (Doug Moen) writes: >>I agree that dynamic type checking is a problem. I had an opportunity >>to play with Alan Bornings "ThingLab" and Randy Smiths "Alternate Reality Kit". >>These are both large applications written in Smalltalk. >>I was able to cause both programs to seize up with "message not understood" >>errors just by playing around. Although Smalltalk is great for rapid >>prototyping, it isn't suitable for programming large, *robust* applications, >>because you can never be sure that you haven't found all the type errors. > >I am not sure if this is valid. Aren't Thinglab and ARK just research >projects and not finished applications? There are a few commercial >applicatiosn written in Smalltalk (e.g., the Humble expert system from >Xerox). It would be more meaningful to look at one of these and see how >reliable it is. Most indeed! In fact, ARK is still in a state of constant evolution, so this kind of behavior is almost to be expected. Humble, (and other applications, such as the Analyst, both from Xerox Special Information Systems), are much more stable and robust. One might also consider ``applications'' like the Browser interface. Such exceptions are extremely rare here. -- -bob atkinson "I do not think, therefore I am a moustache." - J.P. Sartre, "Nausea"