Hiding class pointers -- was it a good idea?

[James Dennett]

Walter Bright wrote:
> Gregor Richards wrote:
>> OK, OK, I guess I should respond with an argument from computer
>> science as well :)
>>
>> In the normal definition of Object Orientation, an object is a means
>> of storing a context in which operations can be performed. The
>> abstraction behind this (yay we're modeling the universe in code but
>> realistically we aren't yay) is irrelevant, as fundamentally OO is
>> just a means of storing and passing contexts. Because this is a
>> context, it makes no sense whatsoever to pass it around with
>> duplication - duplicating contexts is nonsense.
>>
>> structs are sort of a hack for compatibility and/or optimization. They
>> are not contexts, they are means of creating more complicated values.
>> While a "Point" could be a struct, really being a more complicated
>> value, an "NPC" would always be a class, since it is a context.
>>
>> The fact that this is inconsistent with C++ is irrelevant: D is more
>> to the spirit of good OO.
> 
> You put your finger on the very good reason why polymorphic, inheritable
> types in D are restricted to being reference types, not value types. OOP
> requires this characteristic.

For one, rather restricted, notion of OOP.  There are many,
many views of what constitutes OOP in the PL community.

> In C++, an OOP class can be used/misused by the user as a value type or
> a reference type, all out of the purview of the class designer. The
> class designer must control this, not the class user.

It's normal in C++ to make "entity" classes (those that
you're calling reference types) noncopyable.  It's also
normal to make base classes abstract.  Thus idioms easily
prevent the basic misuses.

I can't think of any reason why a value type would object to
the identity of its objects being used (though functional
languages often hide object identities).

-- James