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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public 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: rmartin@oma.com (Robert C. Martin) Subject: Re: OO, C++, and something much better! Date: 1997/01/28 Message-ID: X-Deja-AN: 212837730 references: <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <6PE5zLpF3RB@herold.franken.de> <32E8DC1C.4871@rase.com> organization: Object Mentor Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.object Date: 1997-01-28T00:00:00+00:00 List-Id: In article <32E8DC1C.4871@rase.com>, tansel@rase.com wrote: > Contrary to what people say, type checking is against the nature of > object oriented systems development. Remember, in OO, we only care about > the interface of the other object. This statement is oxymoronic. A type is defined by the interfaces it accepts. There is no other definition of a type. Thus, the statement above could be translated as follows: "...type checking is against the nature of OO...in OO we conly care about the type of the other object." In fact, type checking is at the very *heart* of OO. The current debate has nothing to do with whether types ought to be checked or not, indeed they *must* be checked. The current debate is simply arguing about *when* those types will be checked. In ST, users send messages to objects. They must be reasonably sure that the object they are sending the message to can respond to that message. So they are performing the type checking in their head. The language performs the same check later on, at run time. In C++, the compiler insists that all types are declared, so that when a programmer sends a message to an object, the compiler can be 100% certain that the object can accept that message. Thus, no run time check is necessary. > In fact it should be an OO sin to ask > the type, because, in theory, we don�t want to get intimate with objects > we are interacting apart from their interface. We typically don't have to ask the type of an object. In ST, the language will do the asking for us at run time. In C++ the compiler has done it at compile time. However, there are times both in ST and C++ where we are given an object of unknown type and we do not want to send that object a message until we *know* it can deal with it. Thus in ST we use 'respondsTo' and in C++ we use 'dynamic_cast'. Both of these are essentially run time type checks that can be applied by the programmer. > We only want to know the interface. Which *is* the type. However, in ST we are interested only in a subset of the interface; thus we are interested only in that portion of the 'type' that responds to our message. In C++ we approximate this ability to be interested in partial types by using MI and creating true partial types. (i.e. supertypes that declare only part of a particular subtype) This is why MI is not important to ST, but is critical to C++. > one obvious solution that > comes to mind is to offer an interface signature, that will indicate > that an object really offers all the services that it is required. This > will guarantee that type of the object can change any time as long as > the public interface signature of the object does not change. Then any > object binding to this object can ask its signature rather than type to > verify that > the interface is the same as this object was created. This has run time > costs associated with it, but solves many problems that are associated > with type checking. Furthermore it is not practical for many ADT based > languages. In fact it is identical to dynamic_cast in C++ where the public interface that you mentioned is an abstract superclass of the object being checked. Java has a similar mechanism (isInstanceOf) and so does Eiffel (=?). > In most ADT based languages type checking is done at the compile time. > This approach gives us a lot of safety, but also has an expensive price > tag in terms of flexibility and compromise of object oriented approach. No, the cost is not in flexibility. The cost is in the time required to declare all the types and manage the dependencies appropriately. Flexibility is not encroached upon. The development time argument is a strong one. The declaration of all types is somewhat onerous. Java helps this out by building the declarations into the implementations, but the dependency management issues is still present. In ST, declarations and dependency management are much less of a concern since all declarations are implied and none are checked until runtime. On the other hand, the benefit of static languages is in the fact that they can be made very run time efficient, by doing all the type checking at compile time. Morevoer, once compiled we *know* that there are no type errors lurking in the runnable code. (Unless purposely put there by casts). > There can not be much done to increase flexibility of such languages. > One of my solutions for flexible systems such as Smalltalk is, to use > high level tools to automatically embed type or interface checking code > in development and testing phase, and after all tests are done, to > remove these checks automatically, allowing systems to run without type > checking once they are in production. This gives me best of the both > worlds." Actually it give the worst of both worlds. The lack of type checking is of benefit only during development. Once the program is known to work, type checking is useless. By putting a type-checker in front of the Smalltalk compiler (i.e. stlint ;^) you effectively introduce all the disadvantages of C++ declarations and dependency management without providing the benefit of efficient execution. Once you remove the stlint, the run time system is still doing run-time type checking (i.e. looking up method invocations) > Eighth: Performance. Actually this is a non-issue. I never suffered from > performance apart from screen drawing, or number crunching. In most cases ST preformance *is* a non-issue. But there is a large class of applications that require hard real time performance, and which will not be able to tolerate ST. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan