XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Tue, 21 Feb 2006 14:33:55 +0300, Maxim S. Shatskih wrote:   
      
   >>>> No it is a contract violation.   
   >>>   
   >>> Why is this bad?   
   >>   
   >> That depends. If your bank breaks the contract and plunders your money,   
   >   
   > I cannot understand how dispatching from a method can be equalled to bank   
   > cheating. Really cannot. For me, re-dispatching from the method is a   
   convinient   
   > C++ thing, which also exists in several other OO languages - Borland   
   > Pascal/Delphi and Java at least.   
      
   They all share this deficiency.   
      
   > More so. In C++, you can use:   
   >   
   > struct Foo   
   > {   
   >     virtual void Print() {   
   >         printf("Foo!\n");   
   >     }   
   >     virtual void DoPrint() {   
   >         Print();   
   >     }   
   > };   
      
   The pattern you are trying to express in C++ is:   
      
      type Printable is tagged ...   
      procedure DoPrint (What : Printable'Class);   
      procedure Print (What : Printable) is abstract;   
      
   DoPrint is class-wide. It works for all types derived from Foo. It has the   
   same implementation for all of them:   
      
      procedure DoPrint (What : Printable'Class) is   
      begin   
         Print (What); -- This dispatches   
      end DoPrint;   
      
   DoPrint is not a method. It cannot be overridden. The contract of DoPrint   
   is: "give me anything Printable."   
      
   Print in this case is a [partial] implementation of. Each descendant of   
   Printable have to implement it. The contract of Foo.Print is: "give me   
   nothing but Foo":   
      
      procedure Print (What : Foo) is   
      begin   
         Put_Line ("Foo"); -- I know, it is indeed Foo!   
      end Print;   
      
   The following would result in compile error:   
      
      procedure Print (What : Bar) is   
      begin   
         DoPrint (What);   
            -- Type error What is Bar, it isn't Printable'Class. These   
            -- are different types.   
      end Print;   
      
   And this is indeed an error, because this implementation of Print bears an   
   infinite recursion.   
      
   >> If you aren't interested in software quality, well, some people would never   
   >> board a jet, or drive a car, or turn a computer on.   
   >   
   > Can you be more detailed?   
      
   No. It's confidential information. Though you might search internet for   
   some statistics about the rate of software faults in cars.   
      
   >> Now, putting my software architect's hat on: a need in re-dispatch often   
   >> indicates a design problem. C++ let these problems slip undetected. There   
   >> is a very common special case, when an abstract method is called from   
   >> another method [the latter should be class-wide instead.]   
   >   
   > What is the difference between the "method" and the "class-wide procedure"?   
      
   Method = polymorphic subroutine of a class.   
   Class-wide = non-polymorphic subroutine of a class.   
      
   A polymorphic subroutine has the body distributed over particular derived   
   types. Derived types are responsible for corresponding implementations of.   
   They have to override it. [ Method inheritance is a special case of   
   automatic overriding. ] Polymorphic subroutine is covariant in the   
   corresponding argument (result).   
      
   A non-polymorphic subroutine has one body. When it is defined for all   
   derived types, then is called class-wide. Non-polymorphic subroutine is   
   contravariant in the corresponding argument (result).   
      
   > Is   
   > C++'s virtual member function - a method? or a class-wide procedure? In fact,   
   > everything is class-wide in C++.   
      
   No.   
      
   1. It is not class-wide in the parameters passed by value.   
   2. Constructors and destructors are never class-wide.   
   3. It is not in the result returned by value.   
      
   This shows how inconsistent C++'s model is. By-value vs. by-reference   
   clearly has nothing to do with the issue. For construction/destruction one   
   surely needs dispatching. It is one of the most common errors among C++   
   programmers to believe that calls from c/dtors dispatch. The result of 3 is   
   that you cannot return a polymorphic object on the stack. This has a   
   devastating performance effect, because all abstract factories have to use   
   the heap instead. This is also why a polymorphic object cannot be copied in   
   C++:   
      
   void Foo (T& X)   
   {   
      T Y = X; // Not a copy! T isn't T'Class   
      ...   
   }   
      
   >> worms. Consider two siblings doing +. Now imagine that this happens in the   
   >> brake-by-wire system of *your* car.   
   >   
   > That's why I prefer such systems to be coded in C by competent people (from   
   > what I know, they are really mainly such).   
      
   Yes, it would be safer, just because in this case the project would be   
   canceled long before software deployment! (:-)) [ Developing costs in ANSI   
   C are extremely high for a quite poor quality. As for maintenance costs...]   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)