NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/objectiv/482

Text File | 1992-08-27 | 5.1 KB | 109 lines

Newsgroups: comp.lang.objective-c
Path: sparky!uunet!gatech!udel!louie!hercules.cis.udel.edu!carroll
From: [e-mail] (Mark C. Carroll)
Subject: Re: Objective-C vs. C++
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News Service)
Nntp-Posting-Host: hercules.cis.udel.edu
Organization: University of Delaware, Newark
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Aug 1992 15:31:18 GMT
Lines: 96

In article <[e-mail]> [e-mail] (Eric Taylor) writes:
>Obj. C does not have multiple inheritance.
>I find the a BIG loss.

Why?

In general, I find a lot of people who _talk_ about how wonderful and
essential multiple inheritance is to serious programming. But in real
day to day programming, I've only seen two ways in which it is really
useful:

  1> In C++, MI is used to "cheat" the type system. C++ requires
    that you declare a type for each parameter to a procedure. The
    "type" of an object is used to determine the set of methods
    which you are allowed to call on that object during the
    procedure. If there are several different suites of messages
    that a given object may want to be able to call, you've got
    to declare several superclasses, each of which presents one
    of the method suites that you want to use.

   For example, in a project that I'm currently working on, I've got
   objects which are sometimes treated as mutable data, and sometimes
   as executable code. In C++, I'd have to implement two superclass,
   class Mutable, and class Executable, and when I used one of the objects,
   I'd have to declare it as either Mutable or Executable depending on
   the way in which I was using it. For my application, it _really_ doesn't
   make sense for this kind of object to inherit from _either_ of those
   classes, but if I want to be able to use it the way I need to, I need
   to create an artificial inheritance relationship in order to convince
   the type system to allow me to use them.

    In Objective-C, the dispatch system is different, and you don't have
    to declare a type to define the method suite that you are going to
    use. (The flip side of that is that you _do_ need to write an error
    handler for innappropriate method calls. But the ability to do that
    is built into the language in a very simple and elegant way.)

  2> In languages like CLOS, people do "mixin" programming, which is
    similar to the "protocol" multiple inheritance of the newest version
    of C++. Mixins are similar to the above described usage; the difference
    is that the inheritance relation is considered to not be the is-a
    relation, but rather the "implements" relation. So if A inherits from
    GarbageCollectable, that means that A implements the methods of
    the class named GarbageCollectable. Mixin programming typically makes
    use of _extremely_ large numbers of very small classes. The C++ object
    model is very bad at mixin style programming.


>Objective C syntax is even weirder in class
>definition than C++.

This I don't understand at all. The syntax is actually _clearer_ in
Objective-C, and I don't think that either is wierd. (The reason that
I say the Objective-C is clearer is because methods and instance
variables are clearly seperated in Objective-C, whereas I find it easy
to jumble them in C++ because they are interspersed. Personal taste
and personal brain-damage, but I _really_ think that they should be
seperated, because they are conceptually two completely different
things.)

>I don't seen to remember any operator overloading
>in Obj. C  I may be wrong.

Depends what you mean by "operator overloading".

C++ allows you to bind method calls to operations in standard C
syntax.  So, in effect, C++ has said that "x+y" does _not_ mean add x
to y; it means call the function "operator+(x,y)".

Objective-C doesn't do that. The designer of Objective-C decided that
the meaning of method calls (Object-dispatch) was fundamentally
different from the meaning that is automatically associated with the
standard operations of a programming language, the two should be
syntactically distinguished. So in Objective-C, all method calls are
done using method call syntax, to clearly distinguish dispatch from
primitive operations. So, to add two objects, you need to call
something like "[a add: b]".

But on objects, "operations" are method calls, and those can be
overloaded to your hearts content. So for _any_ operation you
perform on an Objective-C object, it is overloadable. It just has
to be expressed in method-call syntax.

Now, please, can we try to prevent this from expanding into yet
another My Language Can Beat Up Your Language argument? C++ and
Objective-C are two different languages designed for two different
purposes where each is better at what it was designed for!

    <MC>


--
|| Mark Craig Carroll: <MC>     || "Humanity isn't a physical description,
|| Univ of Delaware, Dept of CIS|| it's a spiritual goal. It's not something
|| Grad Student/Labstaff Hacker || you're given, it's something you earn."
|| [e-mail]             ||     - _One_, by Richard Bach