johnson@m.cs.uiuc.edu (08/13/90)
Brad Cox says: >My IEEE Software paper (Nov 1990) goes into the distinction between >specification and implementation in some detail, and argues that we must >stop relying so heavily on inheritance in our implementation tools, and >start devoting as much attention to creating specification tools as we >have on OOPLs. This doesn't mean ripping out inheritance from existing >OOPLs, but just knowing that the meaning of inheritance as supported there >is as an implementation tool, not a specification tool. I agree that inheritance as supported in current languages is more of a implementation tool than a specification tool. That is why Typed Smalltalk separates types and classes. Types are specification and classes are implementation. Instead of class inheritance, the type system uses type inclusion. I disagree with Brad in that I place a much greater emphasis on static specifications than he does. Perhaps this is because I'm an academic. Types in Typed Smalltalk only let you prove that the value of a variable understands certain messages, or is in a certain class. However, I am interested in enhancing it so that more can be said about a program. In particular, I think that Brad's example with stacks (if I push 1,2,3 on an instance of class Stack, pop should return 3,2,1) is the sort of thing that should be done statically. Both testing and static checking are important. However, my basic philosophy is "Never put off until run-time what you can do at compile time." which is a quote from David Gries's compiler book. Of course, being a Smalltalk programmer, my definition of what you can do at compile time is significantly different from Gries's, but I agree with him on this point. Ralph Johnson - University of Illinois at Urbana-Champaign
cline@cheetah.ece.clarkson.edu (Marshall Cline) (08/16/90)
In article <77500053@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes: >However, I am >interested in enhancing [Typed ST] so that more can be said about a program. >In particular, I think that Brad's example with stacks (if I push 1,2,3 >on an instance of class Stack, pop should return 3,2,1) is the sort of >thing that should be done statically. Doug Lea and I are working on just such a system (semantic information encoded into a class, static inference on this `behavioral' information, etc). The idea is to do as much static testing as possible (given the constraints of whatever inference engine you buy at the corner store), and generate runtime tests on cases that are ``too hard''. Naturally there will be many of these. The goal, however, is to provide a system where the source code is flexible, and where static analysis will check your work (presumably finding some errors). Our scheme is called A++ (for ``Annotated C++''). We're presenting a paper on it at this year's Symposium On Object-Oriented Programming Emphasizing Practical Applications (SOOPPA -- pronounce it like a Long Islander would say ``super''). Marshall Cline PS: SOOPPA is Sept 14-15, Marist College, Poughkeepsie, NY. I suspect you can get admission etc from: James Ten Eyck, General Chairperson Marist College 82 North Road Poughkeepsie, NY 12601 (914) 471-3240 x 601 Email: jzbv@maristb.bitnet -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================