Path: utzoo!attcan!uunet!know!cs.utexas.edu!milano!cadillac!vaughan@mcc.com
From: vaughan@mcc.com (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: C++, Object Design Methodologies and Software Engineering
Message-ID: <12866@cadillac.CAD.MCC.COM>
Date: 5 Nov 90 17:20:30 GMT
References: <24872@uflorida.cis.ufl.EDU> <2390@lupine.NCD.COM> <12823@cadillac.CAD.MCC.COM> <SCP.90Nov4140734@grizzly.acl.lanl.gov>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: vaughan@mcc.com (Paul Vaughan)
Organization: MCC VLSI CAD Program
Lines: 52
In-reply-to: scp@acl.lanl.gov (Stephen C. Pope)


   From: scp@acl.lanl.gov (Stephen C. Pope)
   vaughan@mcc.com (Paul Vaughan) said:

   Paul>    From: rfg@NCD.COM (Ron Guilmette)

   Ron>    A related question was discussed awhile back, i.e. the question of
   Ron>    why C++ can't be a bit more like Ada.

   [...]

   Paul> I've suggested this sort of thing for different reasons before, but it
   Paul> hasn't sparked any enthusiasm.  I proposed that this sort of
   Paul> declaration would help to solve severe modularity problems.  One thing
   Paul> that became clear to me was that a very complete declaration is
   Paul> required.

   There are other problems.  Like inlined methods, which can't be used
   in this way since the compiler must know about the implementation
   (data members) of the class to generate inline code.

   stephen pope
   advanced computing lab, lanl
   scp@acl.lanl.gov

I may be missing something here, but I don't really see inline methods
as being a problem, especially when using this as a technique to
enhance modularity, rather than data hiding. Inline methods can only
be inlined in modules where the inline method definition is present.
In my proposal, the class definition must be available in order to
define any method of that class. So if you've got the class
definition, you can define inline methods and they can be inlined.  If
you haven't got the class definition, you can't have any inline method
definitions, and obviously, they can't be inlined.  This really isn't
any different from the current situation.

So, it comes down to a tradeoff between modularity and speed.  The
more stuff you dump into a module, the more potential for inlining and
speed you get.  Having the ability to declare methods (and data
members, BTW) in this way gives the originator or user of a class the
flexibility to make this tradeoff.

The biggest problem that I see is that it transfers even more duties
to the linking stage.  I believe it can be handled there, but the
error messages (for instance, about using a method declared
independently as public but listed as private in the class definition)
aren't going to be as precise as we've come to expect.  Also, I don't
know much about how well it can be supported by a compiler that first
produces C code.

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan