Manfred Nowak wrote:
> Traveler Hauptman wrote:
> 
> [...]
> 
>>On "assignment" I clean up the calculation stack. In
>>debug/profile mode I also collect calculation statistics.
> 
> [...]
> 
> I see. Now please explain, what should happen with expressions like
> 
> x= y= b= c= c + 2.0 * a + a * b + 10.0;
> 
> Especially if x and y are of types derived from your vector class?
> 
> Are you able to present a homogene solution under all aspects?
> 
> -manfred

Let me preface by saying I do not have any experience with inheritance. Assign (no pun intended) credibility as you will.

I think you are asking what the super level copy/cleanup will do when it is called with no overloaded copy/cleanup of it's own? Yes, it will NOT work.

But why does that matter? Most classes will need this(){} methods and if they don't; it's assumed you want defalt values assigned. Derived classes, as I understand it, will have this(){mythis();super();}.

So for value copy from one location to another (opAssign) defalt to moving the values as you would a struct. If that doesn't do it for you then void opAssign(){myopAssign();super.opAssign();} should do the trick?

IMO the power of classes is that they are an opportunity to teach the computer a new type. Types have:

*Memory allocation/deallocation (new/delete) <- Well done in D (Except for the dependance of the std lib on the GC)

*Initialization/Cleanup (this/~this) <- The addition of (type x = void;) brought it all together.

*Value copy (double a,b; a =b;) <- not well done in D

*Collection access (double* a;double[4] b; a++; a = a + a.sizeof;*a = b[2];) <- You can overload the operators if you need it.

*Temporary storage for compound expressions (a = b + c + d;) <- What led me to use my own calculation stack...

The Computer scientists out there can add to the list...

D is a great language. I represent the enormous population of high performance robotics programmers. ;) I would love to use D instead of C. It's so close... But I can't use it yet.

-traveler

>
>I fully agree that not having assignment overloading is severely limiting. One reason may be that classes are reference types. If classes started overriding opAssign, you would have to resort to pointers to classes to make pure references.
>

http://www.digitalmars.com/d/class.html

You are correct. "Class objects are instantiated by reference only." This makes the possibility of creating an assignment operator virtually impossible. How would you tell whether the user wants to assign by reference or by value (how can you even assign by value when you only have references?)?

On Mon, 21 Nov 2005 23:08:53 +0000 (UTC), Ben Phillips wrote:

>>
>>I fully agree that not having assignment overloading is severely limiting. One reason may be that classes are reference types. If classes started overriding opAssign, you would have to resort to pointers to classes to make pure references.
>>
> 
> http://www.digitalmars.com/d/class.html
> 
> You are correct. "Class objects are instantiated by reference only." This makes the possibility of creating an assignment operator virtually impossible. How would you tell whether the user wants to assign by reference or by value (how can you even assign by value when you only have references?)?

So the limitation is that we only have /one/ assignment operator available for us to use, even though we have /two/ types of assignments possible: copying references, and copying values.

I've assumed that the standard convention for copying value is the dup()
method, as in ...

   Foo a = new Foo(4);
   Foo b = new Foo;
   b = a.dup();


A new assignment operator that *only* means copy value might be a useful addition then.

   b := a;

regardless of whether 'a' and 'b' are classes, structs, or native types. In all cases the coders is asking the compiler to copy values. For structs and classes it would call the opCopyValue() method if defined otherwise fail.

So ...
   b := a;
would be that same as
   b.opCopyValue(a);

which allows for overloading possibilities for different data types.

In the case of native types it would be exactly equivalent to the current '=' operator.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/11/2005 10:40:48 AM

In article <1mfot7cqsdo1x$.1hbjalv1cpfbb.dlg@40tude.net>, Derek Parnell says...
>
>On Mon, 21 Nov 2005 23:08:53 +0000 (UTC), Ben Phillips wrote:
>
>>>
>>>I fully agree that not having assignment overloading is severely limiting. One reason may be that classes are reference types. If classes started overriding opAssign, you would have to resort to pointers to classes to make pure references.
>>>
>> 
>> http://www.digitalmars.com/d/class.html
>> 
>> You are correct. "Class objects are instantiated by reference only." This makes the possibility of creating an assignment operator virtually impossible. How would you tell whether the user wants to assign by reference or by value (how can you even assign by value when you only have references?)?
>
>So the limitation is that we only have /one/ assignment operator available for us to use, even though we have /two/ types of assignments possible: copying references, and copying values.
>
>I've assumed that the standard convention for copying value is the dup()
>method, as in ...
>
>   Foo a = new Foo(4);
>   Foo b = new Foo;
>   b = a.dup();
>
>
>A new assignment operator that *only* means copy value might be a useful addition then.
>
>   b := a;
>
>regardless of whether 'a' and 'b' are classes, structs, or native types. In all cases the coders is asking the compiler to copy values. For structs and classes it would call the opCopyValue() method if defined otherwise fail.
>
>So ...
>   b := a;
>would be that same as
>   b.opCopyValue(a);
>
>which allows for overloading possibilities for different data types.
>
>In the case of native types it would be exactly equivalent to the current '=' operator.
>
>-- 
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>22/11/2005 10:40:48 AM

Thats the best idea I've heard, though it might be easy to mistake ":=" for "=" when skimming over code.

In article <1mfot7cqsdo1x$.1hbjalv1cpfbb.dlg@40tude.net>, Derek Parnell says... <snip>
>So the limitation is that we only have /one/ assignment operator available for us to use, even though we have /two/ types of assignments possible: copying references, and copying values.
>
>I've assumed that the standard convention for copying value is the dup()
>method, as in ...
>
>   Foo a = new Foo(4);
>   Foo b = new Foo;
>   b = a.dup();
>
>
>A new assignment operator that *only* means copy value might be a useful addition then.
>
>   b := a;
>
>regardless of whether 'a' and 'b' are classes, structs, or native types. In all cases the coders is asking the compiler to copy values. For structs and classes it would call the opCopyValue() method if defined otherwise fail.
>
>So ...
>   b := a;
>would be that same as
>   b.opCopyValue(a);
>
>which allows for overloading possibilities for different data types.
>
>In the case of native types it would be exactly equivalent to the current '=' operator.
>
>-- 
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>22/11/2005 10:40:48 AM

It's a bit late for it now but it was a curious decision to have class declarations be different than all others:

void*,int* vs class* <- Screwed me up for a while.

'=' works fine without needing another operator if your syntax is consistent. (*foo = *bar; foo = bar;) Compile time type checking will catch any errors.

Perhaps restating what Derek is saying, it would be interesting to consistently seperate assignment for values and assignment for references. So it would be obvious when an expression is working with pointers vs working with the object itself.

double* a,b;
double c,d;

a := &c;
b := a;
c = d;
c = *a;
a := c; <- illegal
c = a; <- illegal






Traveler Hauptman
www.barrett.com

Derek Parnell wrote:
> On Mon, 21 Nov 2005 23:08:53 +0000 (UTC), Ben Phillips wrote:
> 
>>> I fully agree that not having assignment overloading is
>>> severely  limiting. One reason may be that classes are
>>> reference types. If classes started  overriding opAssign,
>>> you would have to resort to pointers to classes to make
>>> pure references.
>> 
>> http://www.digitalmars.com/d/class.html
>> 
>> You are correct. "Class objects are instantiated by reference
>> only."  This makes the possibility of creating an assignment
>> operator virtually  impossible. How would you tell whether
>> the user wants to assign by reference or by  value (how
>> can you even assign by value when you only have references?)?
> 
> So the limitation is that we only have /one/ assignment operator
> available for us to use, even though we have /two/ types of
> assignments possible: copying references, and copying values.
> 
> I've assumed that the standard convention for copying value is the
> dup() method, as in ...
> 
>    Foo a = new Foo(4);
>    Foo b = new Foo;
>    b = a.dup();
> 
> A new assignment operator that *only* means copy value might be a
> useful addition then.
> 
> b := a;
> 
> regardless of whether 'a' and 'b' are classes, structs, or native
types. In
> all cases the coders is asking the compiler to copy values. For
structs and
> classes it would call the opCopyValue() method if defined otherwise
> fail.
> 
> So ...
>    b := a;
> would be that same as    b.opCopyValue(a);
> 
> which allows for overloading possibilities for different data types.
> 
> In the case of native types it would be exactly equivalent to the
> current '=' operator.

You know, that sounds really intriguing!

Derek Parnell wrote:
> I've assumed that the standard convention for copying value is the dup()
> method, as in ...
> 
>    Foo a = new Foo(4);
>    Foo b = new Foo;
>    b = a.dup();
> 
> A new assignment operator that *only* means copy value might be a useful
> addition then. 
> 
>    b := a;
> 
> regardless of whether 'a' and 'b' are classes, structs, or native types. In
> all cases the coders is asking the compiler to copy values. For structs and
> classes it would call the opCopyValue() method if defined otherwise fail. 
> 
> So ...
>    b := a;
> would be that same as    b.opCopyValue(a);
> 
> which allows for overloading possibilities for different data types.
> 
> In the case of native types it would be exactly equivalent to the current
> '=' operator.
> 

I think this has been discussed before, but someone didn't like the Pascal-style syntax ":=". It would be cool to have at least some kind of user-controlled shallow/deep-copy operator for classes. Somehow := looks a lot nicer than a copy constructor or foo.clone().