Tristam MacDonald wrote:
> Alex Burton wrote:
>> Walter Bright Wrote:
>>
>>> 1) inheritance
>>> 2) polymorphism
>>> 3) encapsulation
>>
>> Another one in that list should be "reference", which IMO would be
>> assumed by most people, but has been lost with transitive const in D.
>> I would define it as the ability to not encapsulate something a class
>> has a reference to.
>> By making all objects that an object has references to necessarily
>> part of that object, the transitive const feature means that the only
>> state relationship a class can have to another class is encapsulation.
>>
>> Correct me if i'm wrong :)
>
> Agreed, but I can't think of another language that supports this definition of OOP (apart from 'mutable' under C++ - which is widely regarded as a hack).

About every OO-aware language but D supports it; only D (2.0) assumes in its type system that reference to another object always implies a whole-part relationship between them.

"mutable" isn't much related to this (and note that widely held opinions are often not shared with informed experts).

-- James

Walter Bright wrote:
> James Dennett wrote:
>> Walter Bright wrote:
>>> James Dennett wrote:
>>>> Walter Bright wrote:
>>>>> Value types are fundamentally different from reference types. D gives you the choice.
>>>> C++ gives you *more* choice by allowing easier migration between the two without imposing performance or syntactic differences.
>>> That isn't my experience. In my work on DMDscript in D, I changed some types between struct and class to try out some variations, and found it to be a lot easier than in C++. For one thing, I didn't have to find and edit all the -> and .'s.
>>
>> In C++, no, you didn't, as structs and classes are no different in their use of "->" and "." (as you're aware, they're all just classes).
> 
> I meant I switched between value and reference semantics for an object.

Careful with selective quoting!  I recognized that you
probably meant this fundamental change of semantics with
my very next paragraph, reproduced below:

>> Now, if you changed from using objects by value to using them by reference, it would be dangerous to take the D route and use almost the same syntax for both (for example, you inherit the ubiquitous Java bug of writing MyType foo; and finding that foo is null rather than being a usable object).

Similar concept should look similar; similar syntax should have similar semantics.  You've chosen to use (almost) the same syntax to mean two very different things, with subtle gotchas such as the simple but pervasive bug noted above.

-- James