NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/cplus/19764

Internet Message Format | 1993-01-22 | 5.4 KB

Xref: sparky comp.lang.c++:19764 comp.object:5002
Path: sparky!uunet!olivea!pagesat!spssig.spss.com!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Message-ID: <[e-mail]>
Date: 22 Jan 93 15:54:14 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
Lines: 97

In article <[e-mail]> [e-mail] (Philip Santas) writes:
>In article <[e-mail]> [e-mail] (Dave Griffith) writes:
>> [e-mail] (Philip Santas) writes:
>>
>>You have asserted that this is not a problem in languages in which primitives
>>are classes (Smalltalk, Axiom/Scratchpad).  The problems I discussed are
>>still present in those systems.  C++'s (IMHO) inconsistent design decision to
>>treat primitives as non-class types is hardly a point in it's favor.
>
>What I said is that you cannot redefine the primitives, and I gave you
>the reason why. I have never said that this separate treating is of any
>language's favour. (you definitely have a way of "inventing" statements
>and atribute them to other people :-(  )
>

I never suggested that you did suggest any such thing.  You're the one
inventing statements here.

>>>I understand that you want to substitute a symbol, say "=", with one value
>>>all over your formalism, but the fact that you cannot do it, does not mean
>>>that the language is complex, it means that you have to find another way
>>>to deal with it. Furthermore, people feel comfortable with operators
>>>like "+" and "*" which have been primitevely overloaded for reals, integers,
>>>etc. There is no reason why not to treat "=" in the same way.
>>
>>If you've still got the archive, the value/object discussion of a month
>>ago makes my position pretty clear on this subject, in probably overly
>>deep detail.
>
>To what extend has this been covered by the object/value discussion?
>

I made at least three prior postings on precisely this point.


>>>Notice also that we deal with a non-trivial type system (I do not discuss
>>>how it is implemented, this is another story)
>>>Denotational semantics have elegant approaches on simple type systems,
>>>but for more complicated ones they are confusing. Notice that by
>>>assuming _traditional_ subclassing, you have a form of overloading "=",
>>>since the objects have (od do not have) to coerce to the superclasses
>>>in many cases. This overloading occurs with every link you add.
>>
>>Nonsense.  In traditional subclassing, there is no concept of coercing to
>>the superclass at all.  Coercions, if they occur, are utterly orthogonal to
>>the subclassing heirarchy.  C++ implements this _very_ poorly (truncating
>>objects if passed by value!) but calling this traditional inheritance is
>>just wrong.
>
>I hope you are familiar with the terms "reference semantics" and "value semantics".
>Coercions do occur when you move the object to the superclass in "value semantics".
>Are you saying that traditional subclassing does not involve values?
>
>Furthermore, you definitely coerce an object when you move it to the superclass,
>since you alter its behaviour. If you don't believe me, make equality tests
>on objects of differnt classes (which are at the same inheritance path).
>

You're stuck in C++ here.  This is not the case in many other OO languages,
and in only makes sense in C++ because of it's C roots showing through.  In
Smalltalk and Eiffel, everything you describe would be just overly baroque
nonsense.

>>As much as I would love to spend the next decade (a conservative estimate)
>>working on a formal definition of C++, I'm forced to pass.  Even suggesting
>>that someone might need to put in that huge amount of work to prove this
>>utterly trivial point weakens your case.
>
>"trivial point" = "I don't know how to prove it" :-(
>Right?
>

No, trivial point means that, even if one of us convinces the other, it
will make not the slightest difference to the programs we write or languages
we define.  I have never in this thread argued against overriding primitives,
just that, in a well designed OO language, this is a source of complexity
and should be treated as such.  If it was a _bad_ idea, I wouldn't be
including overridable equality in my language.  You have never shown that
you actually knew enough about formal semantics to view my original statement
as more than a C++ flame to which a knee-jerk response was needed.

A formal definition of Ada without concurrency took over six man years to
produce (NYU, if I remember correctly).  Ada without concurrency is a
much simpler language than C++.  Fewer types, fewer control primitives,
less dynamism, less overriding.  As such, a decade seemed a reasonable
time frame for a formal C++ defn.  You indicated that such a defn. would
be the only argument you would accept. and I declined.  Are you willing
to spend ten years proving your side of this argument?  Of course not, you're
not even willing to spend ten seconds apologizing for flaming.

I again request that we take this to e-mail.

--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
When buying and selling are controlled by legislation, the first things bought
and sold are legislators.