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

[Bill Baxter]

Yigal Chripun wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> Christopher Wright wrote:
>>>> That would be allowed in D, if you could overload T.opAssign(T).
>>>
>>> C++ still has well-known slicing problems, even with overloading 
>>> assignment.
>>>
>>> The question is not "can this be done", it's more "is there a 
>>> compelling reason to support such behavior". I think the answer is 
>>> no. Do you really want a language where a class designer feels 
>>> compelled to define an opassign overload, then make it private to 
>>> prevent people from using the class as a value type? Where the base 
>>> class designer needs to know what the derived classes are doing so he 
>>> can make the destructor virtual or not? Where you cannot have arrays 
>>> of base classes?
>>
>> At least C++ lets you control copying behavior completely in all 
>> circumstances.  And documents what you are supposed to do clearly. 
>> Right now D gives you the choice of
>>
>> 1) [structs] copy by value only, with no option to customize or 
>> intercept copy operations
>> 2) [classes] no defined copy behavior whatsoever
>>
>> 1) makes interesting ref counting wrappers etc impossible, but I think 
>> you're planning to fix that one.
>>
>> I think 2) is a problem also.  It means that developers will each come 
>> up with their own way to copy objects because there's no clear way to 
>> do it.  I think some particular scheme should be crowned, like any 
>> class that wants to be copyable should provide a the pair of methods 
>> dup(), and copy(ThisType).  And maybe there should be something in 
>> Object to this effect also, even if they don't do much of anything.  
>> Looks like java implements a clone() method in the base Object class.  
>> But it looks like that just makes it so you get a runtime exception if 
>> the class you're trying to clone doesn't support cloning.  That 
>> doesn't seem like an improvement over a compile time error.
>>
>> So I'm not really sure what should be done, but I definitely think 
>> something should be done to specify "the D way" to polymorphically 
>> copy objects.  Built-ins mostly have .dup properties, but I don't 
>> think the spec actually says anywhere that user classes that want to 
>> be copyable should have a .dup.  But even specifying a .dup is not 
>> enough I think, because if I derive from some class A, I have to 
>> create my derived class, then get class A to copy the A parts of the 
>> new object somehow, say via a method like A.copy(A copy_from).
>>
>> C++ may have problems regarding copying classes, but D's solution is 
>> effectively to just remove the C++ functionality good and bad.  Ok the 
>> slicing problem is gone, but so is copying.  There should be one 
>> obvious way to make classes in D copyable, whether it be enforced by 
>> the language, compiler, or simply the spec and D community.
>>
>> --bb
> 
> In java you also need to implement a clonable interface which is a 
> marker interface.
> I think that adding a clonable interface to the standard library should 
> be enough. something like:
> ---
> interface clonable {
>     object dup();
> }
> ---
> now you need to implement it to support copying. 

Is there really any benefit in making it an interface in D since you can 
just do a static if check to see if it has a dup method?

> I don't think a dup 
> method should be added to object. as you said, it isn't really an 
> improvement, and usually Java experts recommend avoiding clone().

What do you mean they recommend avoiding it?  What do they recommend 
instead?

> also, i don't see why a copy method is required.
> for example, check the following code:
> ---
> class Base : clonable {
>     Base dup() {
>        auto ret = cast(Base) this.classinfo.create;
>        ret.x = this.x;
>        ret.y = this.y;
>        return ret;
>     }
>     int x = 6;
>     double y = 8;
> }
> 
> class DerivedA : Base {
>     override DerivedA dup() {
>        auto ret = cast(DerivedA) super.dup;
>        ret.w = this.w;
>        return ret;
>     }
>     long w = 42;
> }

Ah ha!  Ok, that's great.  This is exactly what I was looking for over 
on the thread I started on D.learn ("implementing dup/clone for class 
hierarchies").   Steven suggested using classinfo.create, but he left 
his solution using a separate copy() method (or I just misunderstood 
him), and that just ends up in a lot of casting.  But your method seems 
to work.

So that seems good.  The trouble then is just that it is not obvious and 
there are no examples in the documentation showing how to do this.

For now I've added this example to the wiki DocComments page for 'class':

http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Class#section8


But I really think an example like this belongs in the main doc.

--bb