Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore-2!bellcore!maya!caseau
From: caseau@maya.bellcore.com (Yves J Caseau)
Newsgroups: comp.object
Subject: Re: Should classes be objects
Keywords: Garfield
Message-ID: <26428@bellcore.bellcore.com>
Date: 3 Sep 90 11:11:42 GMT
References: <141522@sun.Eng.Sun.COM> <1990Aug30.222809.291@Neon.Stanford.EDU> <3245@cui.unige.ch>
Sender: news@bellcore.bellcore.com
Reply-To: caseau@maya.UUCP (Yves J Caseau)
Organization: Bell Communications Research, Morristown NJ
Lines: 50



Here is my 0.02 cents contribution on this subject. I use a rather peculiar
model of object-oriented programming where classes are ONLY used for 
"classification" (set organization). Behavioural description is done by
attaching type signature to operations or relations. In this context, the 
actual question could be generalized to
  
   What good is reflection?

i.e. Why classes as objects, methods as objects, and so on

My arguments are as follow:

  (1) object-oriented programming is a good technique for developing modular
      and extensible software. The main reasons are the one you can include 
      here (nice abstract interface, inheritance, set taxonomy,....)

  (2) Using OOP for knowledge representation imply designing an extensible
      system as opposed as a "swiss-army-knife"-like language. I need in my
      applications to extend the language with new features (eg: add history
      management to instantiation) and to reason on the language's objects 
      (eg: describe the mathematical properties of methods to include them in
      the inference engine).


So a natural solution is to apply the technique (1) to the problem (2). If
classes are objects, you can easly:

    - complete their description through new methods. If you define a set
      operation package (such as an extended type system), you'll be happy
      to include classes in it.
    - create your new kind of classes (meta-class) to add necessary feature.
      I had a practical example where I needed to implement dependencies
      between objects are some of their slots (i.e. a SSN uniquely determine
      a person). Doing by defining a new sort of class seems to me the
      most generic (and therefore, re-usable) way.


This is rather independant of the model that you use. As far as dogmatic points
are concerned (class as a way to encapsulate behaviour), I really think that
class have a behaviour that should be encapsulated. In my model (the LAURE
language) a class is nothing more that a set defined in an inclusion lattice; 
and the set of all classes is definitely useful, so classes are objects.


-- Yves Caseau
   caseau@bellcore.com

PS: LAURE is an acronym for LAure is Universally REflective