From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Pros and cons of C++
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Fri, 22 Jan 1993 14:25:18 GMT

In article <1993Jan21.231618.8962@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
> santas@inf.ethz.ch (Philip Santas) writes:
>>
>>Since in C++ you _cannot_ redefine primitive operations with means
>>other than macros (and we were not talking about macros), nothing of the
>>problems you mention occur. Notice that equalty on integers, for instance,
>>cannot be redefined. The reason it cannot, is that int is not a class;
>>you can redefine operators only in classes.
>>
>
>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 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?

>>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).

>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?

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch                                Philip Santas
Mail: Dept. Informatik                     Institute of Scientific Computation
      ETH Zurich                          Swiss Federal Institute of Technology
      CH-8092 Zurich                                  Zurich, Switzerland
      Switzerland
Phone: +41-1-2547478
      

Newsgroups: comp.lang.c++