🚀 go-pugleaf

  From: "David C. Martin" <dcmartin@fascet.msi.com>
  Organization: Molecular Simulations, Inc.
  Email: dcmartin@msi.com or uunet!dcmartin
  Phone: 408/522-9236 (O)
  To: Jon L White <jonl%kuwait@lucid.com>
  Cc: kanderso@BBN.COM, dcmartin@msi.com, john@linus.mitre.org, eric@tfs.com, 
      barmar@think.com, comp.lang.clos@cis.ohio-state.edu
  Subject: Re: Beginner's question and method lookup 
  Date: Thu, 20 Aug 92 13:39:30 -0700
  Sender: dcmartin@msi.com
  
  Jon L White writes:
  
      David, if it were possible to do  "complete determination
      i.e. static binding for the executable"  at compile time,
      then there would be no need for "virtual" functions in
      C++.   Do you understand the fundamental problem posed by
      having same-named methods on a class and and on a derived
      (sub) class?  the dispatch from a higher method cannot
      determine at compile time whether or not a sub-called
      method[*] is the one defined on the same statically
      determinable class or one of those defined on a derived
      (sub) class.  I talked about this topic at the CLOS versus
      C++ debate last week at the 1992 Lisp Users and Vendors
      conference.
  
  Yes, I do understand that you can't do *complete* determination, but I meant
  that you didn't always need to do table lookups for cases in which you would
  not use "virtual" functions in C++.  I did not mean that you can always do
  static determination for solutions in all know problem space.  I should have
  been more specific.
  
Yes, but that leads to a rather "sticky" kind of object oriented
programming, if you consider it object oriented at all.  For example, the
function a_function takes a pointer to an instance of a high level object
class, HLObject, and invokes the member function (effective method)
a_emethod on it.

  void a_function(HLObject * x)
  {
    x->a_emethod();  // Always equivalent to x->HLObject::a_emethod().
    // ...
  }

If you pass in a pointer to a class, B, built on HLObject, a_function always
works the same way - not very object oriented.  If you decide you want the
behavior of a_function to depend on class B, you must declare a_emethod
virtual in the definition of the class HLObject.  Hopefully, you have sources.

C++ programmers are encouraged to use non virtual member functions, to
avoid the time space overhead of virtual member functions.  This doesn't
seem to encourage very object oriented programming.

k