Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!ucsd!helios.ee.lbl.gov!ux1.lbl.gov!beard
From: beard@ux1.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C++ - MI and HandleObject
Keywords: multiple inheritance
Message-ID: <5406@helios.ee.lbl.gov>
Date: 14 Apr 90 01:32:59 GMT
References: <255@unf7.UUCP>
Sender: usenet@helios.ee.lbl.gov
Reply-To: beard@ux1.lbl.gov (Patrick C Beard)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 62
X-Local-Date: 13 Apr 90 18:32:59 PDT

In article <255@unf7.UUCP> shite@unf7.UUCP (Stephen Hite) writes:
#
#  The Apple C++ reference says that multiple inheritance cannot be
#used in combination with HandleObject.  Why not?  Also, why is it 
#not possible to allocate an array of handle-based objects?  Will these
#restrictions possibly be lifted in the future? 
#
#  Thanks to the object specialists at Apple for answering this.  
#

Well, I'm no object specialist, but I'll give it a whirl.

As I understand it, Multiple-Inheritance is implemented by generating
code that does address arithmetic on the this pointer to an instance of an 
object, which is bad because this is a handle for handle-based objects.
On pg. 37 of the latest MPW 3.1 C++ reference manual it says that no address
arithmetic may be performed on a pointer to a handle based object, except 
for the implicit arithmetic of a member reference.  So, I suppose that since 
Apple hasn't gotten around to implementing address arithmetic for these classes,
that's why MI can't be used.

In theory, I believe that MI should be doable using Handle based classes.  I
think the best way to do it for now, would be to do away with the implicit 
references that Object Pascal uses, such as:

  MyHandleClass* mhc = new MyHandleClass;
  mhc->methodCall();

and move to a more explicit use of Handles:

  MyClass** mc = new MyClass;  // new overloaded to return void**, not
                               // just void*, or how about hnew to return
                               // handles...

  (**mc).methodCall();         // call handle allocated class.

                               // this would be a pointer, as it is
                               // in the automatically allocated case, 
                               // (*this).field would be generated
                               // for every member reference in the method.

Now, since this is a pointer to the object that was allocated as a handle, 
member references could be unsafe.  Instead of writing methods that know that
they are handle based, one could implement a Lock method that could be called 
before pointer references are used:

  (**mc).Lock();               // lock the this pointer for pointer access.
  MyClass* mcptr = *mc;

  mcptr->methodCall();         // call with pointer reference.


This would allow both handle implemented classes AND Multiple Inheritance.

Any object specialists listening?



-------------------------------------------------------------------------------
-  Patrick Beard, Macintosh Programmer                        (beard@lbl.gov) -
-  Berkeley Systems, Inc.  ".......<dead air>.......Good day!" - Paul Harvey  -
-------------------------------------------------------------------------------