what was wrong with struct & class in C++?

[Martin Hinsch]

On Wed, 12 Dec 2007 14:59:16 -0800, Gregor Richards wrote:

> Martin Hinsch wrote:
>> On Wed, 12 Dec 2007 12:24:44 -0800, Gregor Richards wrote:
>> 

[snip]

>>>
>>> In C++, this is ANYTHING but simple:
>>>
>>> class A {
>>> ...
>>> }
>>> }
>>> void someidiotfunction(A a);
>>> void someidiotfunction2(A *a);
>>> void someidiotfunction3(A &a);
>>>
>>> You now have three ways of passing an "object", with different
>>> semantics and different possible results!
>>>
>>> In proper object oriented design, objects are contexts. It makes no
>>> sense to duplicate contexts. Contexts are an abstraction of an
>>> environment in which to perform actions, and it makes no sense to
>>> duplicate that environment whenever you happen to pass it from one
>>> function to another (oh except when you don't).
>>>
>>> D is not the problem. C++'s insistence on forcing details of
>>> implementation down the users' throat is the problem.
>>>
>>>   - Gregor Richards
>> 
>> I don't mean to be offensive, but I totally don't see the point. Of
>> course C++ structs (being inherited from C) are too low-level. Still, I
>> would argue that this is a property of C++ not of value-semantics. And
>> who decides a) what "proper object-oriented design" means,
> 
> Consensus and history.

So, you're basically saying follow the crowd since everybody does...

> 
>> b) that it's
>> inherently a great thing
> 
> This is irrelevant. Whether OO is good or not, D aims to be OO.

I thought D had the much more modest goal to be the best language ever
;-).

> 
>> and c) that it is tied to reference semantics?
> 
> Consensus. C++ is popular, but it is the exception to the rule in this
> regard. Virtually no other language has this bizarre property.
> 

see above. I don't think that consensus is a good argument (except maybe
in politics).

>> IMO it makes perfect sense to treat objects as just a more complicated
>> kind of value. Look at the following code:
>> 
>> int a=1;
>> a++;
>> int b = a + 10;
> 
> This code has no function calls. And, if it was all implemented with

I see no reasons to treat operators anything different than as sugarified
function calls.

[snip]
> 
> Intrinsic values do not mutate in the same way that objects do. In an
> object oriented sense, they're immutable. When you say a = a + 5, it's
> rebinding the variable a to a new value, computed as a + 5. The actual
> data representing its original value is not modified, a is simply
> rebound. This has the same result whether by-value or by-reference.
> Because they're immutable, there's no distinction between by-value and
> by-reference passing. If all the intrinsic types were actually by-ref
> objects, there would be no difference.
> 
> (Note: a++ and ++a are sort of exceptions to this rule)

Ok, you have sort of a point. I think what I was talking about was mutable
vs. immutable objects which is a kind of related (and interesting as well)
but still different topic.

> 
>> You can easily make up a way to specify which way to use a function arg
>> (like, say, 'in' and 'inout') without having to know anything about
>> values or references.
> 
> Yes - D already has one.

I know, I was trying (and obviously failing ;-) to be sarcastic.
Anyways, the point I was trying to make is that your example of all the 
different possibilities to pass objects as function arguments in C++ has
nothing to do with values vs. references but rather with the fact that C++
(as you said) doesn't properly abstract from implementation details.
Therefore you have to "construct" the different ways to pass arguments
(modifiable/non-modifiable) from the low-level machinery (i.e. pointers)
or the slightly more high-level half-hearted add-on (i.e. references (&)).
If the language offers you a way to properly describe the semantics of
argument passing this becomes a non-issue.

> 
>> To sum it up - I think although C++ structs + pointers + references is
>> messy, that doesn't mean that OOP and value vs. reference semantics
>> aren't completely orthogonal concepts. And by the way this is the main
>> point keeping me from using D
> 
> Seriously? You are /way/ too much of a C++'er. Go use any other OO
> language, and you will find your opinion very quickly in the minority.

so, minority == wrong?

Actually my first OO language was Objective C which is as referency as you
can get without going directly to SmallTalk. I've also done quite some
programming in Java and Ruby both of which also belong to this
category (albeit one with static and the other one with dynamic typing).
I really liked both, Ruby and Objective C (I strongly dislike Java but for
entirely different reasons). Still, the distinction between object
references on one hand and plain type values on the other hand always
seemed quite artificial to me.

I think it makes kind of sense in a dynamic, "scripty" language where you
would like to ignore types most of the time. As soon as you enter the
statically typed world there is in my opinion not really a good reason
anymore to make objects references per default. 

You can get everything you want from OOP (data hiding, inheritance,
polymorphism) with value types as default.

[snip]
 
> This is a purely syntactic hurdle, and the giant ugly mess that is
> by-value objects is not worth the slightly simpler syntax. Which,
> incidentally, would be more complicated syntax in basically every other
> scenario.
>

Please explain (seriously).
 

Martin Hinsch