Xref: utzoo comp.lang.c++:14473 comp.std.c++:976 comp.lang.smalltalk:3131
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!cs.uiuc.EDU!johnson
From: johnson@cs.uiuc.EDU (Ralph Johnson)
Newsgroups: comp.lang.c++,comp.std.c++,comp.lang.smalltalk
Subject: Re: Register as Object Vendor
Keywords: Objects OOP C++ SmallTalk
Message-ID: <1991Jun29.194144.10714@m.cs.uiuc.edu>
Date: 29 Jun 91 19:41:44 GMT
References: <9281@drutx.ATT.COM>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson)
Organization: University of Illinois
Lines: 31
Nntp-Posting-Host: m.cs.uiuc.edu

This is an interesting idea.  I assume that you mean "classes",
not "objects", since it is pretty hard to sell a single C++ or
Smalltalk object.

There are several technical questions that I have, and one
major socio-economic objection.  The technical questions are
how you are going to specify classes, and how you will know
whether classes meet their specification.  Are you going to
provide formal specifications?  I doubt it, because few people
know how to write or read them.  If you use informal specifications,
how can you possible "prove" that a class works?  At best, you can
provide a set of test cases with your specifications and see whether
the delivered code executes them correctly.  If my class executes
the test cases, but it doesn't meet the informal specifications,
then what?

The socio-economic objection is that "class" is not the correct
granularity of reuse.  People reuse entire systems, or abstract
designs, and then reuse classes that fit into them.  For example,
Smalltalk programmers reuse Model/View/Controller as a framework
for user interfaces.  Once you agree upon this framework, you can
discuss classes for displaying graphs, text, etc.  However, if
you don't have the framework then it will be very difficult to
specify the individual components.

Also, you are describing a top-down specification of components,
which does against the way that most O-O systems are built.
While this is not a proof that your scheme will not work, I am
curious whether you have arguments against the usual O-O style.

Ralph Johnson -- University of Illinois at Urbana-Champaign