I am playing with a numerical class `number'.

First all ops and assigns were functions.

Then I switched to overloading `+' and `*' to use
  number a, b, c; // `new number' omitted
  a= b + c;
and changed my `unittest' cases accordingly. The trivial cases passed.
Then some errors occurred and I decided to include a `trace' field in the
class to allow tracing of the actions in a particular instance of `number'
by stating for example:
  b.trace= true;
  a= b + c;
This worked fine. However, when wanting to trace `a' by
  a.trace= true;
  a= b + c;
I trapped into the mess: the `trace' field of `a' was overwritten by the
`trace' field of `b + c' which of course was not set to `true'.

So I wanted to overload `=' to not overwrite the trace field. No way because of the lack of `opAssign'. I had to include a property `set' to `number' and change all existing `=' to `.set='. That was not only a simple lexical change, because `=' was of course not only used for assigning to `number'.

My number of test cases grew and I made intensive use of the trace feature.

When getting a mysterious result I inserted a printout into a `while' loop to observe a local variable. But there was no output. Conclusion: the loop was not entered. Action: more outputs inserted into the enclosing scopes. Observation: no output. ...

Final observation: did not use `.set=' but only `='. ARRGGGHHH!

However, forbidding of the use of pure `=', for example by declaring it private, is also not possible.

Any suggestions?

So long.

You seem to have a point here.
And it seems that nobody has an idea.

Anyone?

Ciao

In article <c0b6v5$1sel$1@digitaldaemon.com>, Manfred Nowak says...
>
>I am playing with a numerical class `number'.
>
>First all ops and assigns were functions.
>
>Then I switched to overloading `+' and `*' to use
>  number a, b, c; // `new number' omitted
>  a= b + c;
>and changed my `unittest' cases accordingly. The trivial cases passed. Then some errors occurred and I decided to include a `trace' field in the class to allow tracing of the actions in a particular instance of `number' by stating for example:
>  b.trace= true;
>  a= b + c;
>This worked fine. However, when wanting to trace `a' by
>  a.trace= true;
>  a= b + c;
>I trapped into the mess: the `trace' field of `a' was overwritten by the `trace' field of `b + c' which of course was not set to `true'.
>
>So I wanted to overload `=' to not overwrite the trace field. No way because of the lack of `opAssign'. I had to include a property `set' to `number' and change all existing `=' to `.set='. That was not only a simple lexical change, because `=' was of course not only used for assigning to `number'.
>
>My number of test cases grew and I made intensive use of the trace feature.
>
>When getting a mysterious result I inserted a printout into a `while' loop to observe a local variable. But there was no output. Conclusion: the loop was not entered. Action: more outputs inserted into the enclosing scopes. Observation: no output. ...
>
>Final observation: did not use `.set=' but only `='. ARRGGGHHH!
>
>However, forbidding of the use of pure `=', for example by declaring it private, is also not possible.
>
>Any suggestions?
>
>So long.
>
> 
>
> 

I'm not clear on the purpose of the trace field. My first suggestion is to make the trace of the result of a binary operation be true if the trace of either input is true:

 result.trace = x.trace || y.trace;

Remember objects are assigned by reference, not by copying the contents. I'd be surprised if overloading assignment is the best solution for your problem.

-Ben


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c0b6v5$1sel$1@digitaldaemon.com...
| I am playing with a numerical class `number'.
|
| First all ops and assigns were functions.
|
| Then I switched to overloading `+' and `*' to use
|   number a, b, c; // `new number' omitted
|   a= b + c;
| and changed my `unittest' cases accordingly. The trivial cases passed.
| Then some errors occurred and I decided to include a `trace' field in the
| class to allow tracing of the actions in a particular instance of `number'
| by stating for example:
|   b.trace= true;
|   a= b + c;
| This worked fine. However, when wanting to trace `a' by
|   a.trace= true;
|   a= b + c;
| I trapped into the mess: the `trace' field of `a' was overwritten by the
| `trace' field of `b + c' which of course was not set to `true'.
|
| So I wanted to overload `=' to not overwrite the trace field. No way
| because of the lack of `opAssign'. I had to include a property `set' to
| `number' and change all existing `=' to `.set='. That was not only a
| simple lexical change, because `=' was of course not only used for
| assigning to `number'.
|
| My number of test cases grew and I made intensive use of the trace
| feature.
|
| When getting a mysterious result I inserted a printout into a `while' loop
| to observe a local variable. But there was no output. Conclusion: the loop
| was not entered. Action: more outputs inserted into the enclosing scopes.
| Observation: no output. ...
|
| Final observation: did not use `.set=' but only `='. ARRGGGHHH!
|
| However, forbidding of the use of pure `=', for example by declaring it
| private, is also not possible.
|
| Any suggestions?
|
| So long.
|
|
|
|

While it was 2/10/04 6:12 PM throughout the UK, Manfred Nowak sprinkled
little black dots on a white screen, and they fell thus:
<snip>
> I decided to include a `trace' field in the
> class to allow tracing of the actions in a particular instance of `number'
> by stating for example:
>   b.trace= true;
>   a= b + c;

You already have a problem here.  D is not C++.  Object variables aren't the objects themselves, but references to them.

> This worked fine. However, when wanting to trace `a' by
>   a.trace= true;
>   a= b + c;
> I trapped into the mess: the `trace' field of `a' was overwritten by the `trace' field of `b + c' which of course was not set to `true'.

No it wasn't.  The object reference 'a' was overwritten with a reference to a whole new object.

> So I wanted to overload `=' to not overwrite the trace field. No way because of the lack of `opAssign'. I had to include a property `set'
> to `number' and change all existing `=' to `.set='. That was not only
> a simple lexical change, because `=' was of course not only used for assigning to `number'.
<snip>

The = operator on objects has a specific meaning as far as D is
concerned - to copy object references, not the objects (or parts
thereof) themselves.

I think the only reason C++ allows overloading of = is that variables _are_ objects, not just references to them.  Combining this with C++'s lack of GC, assignments sometimes need special handling.

OTOH, in D, with its objects by reference and GC, being able to overload = was deemed pointless for anything but code obfuscation.

Maybe you need to rethink your debug coding strategy.  Or maybe someone else has an idea....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from being the
victim of intensive mail-bombing at the moment.  Please keep replies on
the 'group where everyone may benefit.

> The = operator on objects has a specific meaning as far as D is
> concerned - to copy object references, not the objects (or parts
> thereof) themselves.
> 
> I think the only reason C++ allows overloading of = is that variables _are_ objects, not just references to them.  Combining this with C++'s lack of GC, assignments sometimes need special handling.
> 
> OTOH, in D, with its objects by reference and GC, being able to overload = was deemed pointless for anything but code obfuscation.
> 
> Maybe you need to rethink your debug coding strategy.  Or maybe someone else has an idea....

Maybe D needs a "copy" operator. For value types it would be a direct copy, for classes it would default to memberwise copy and be overridable. (Should it copy members using itself or using =?, ie shallow or deep copy? Not sure. Maybe _two_ operators ;-)
I'd like <- if it wasn't such a parsing nightmare, #= or @= maybe?
Sam

PS is this like what Heron does? I haven't had a chance to look at it yet.

Sam McCall wrote:

>
> Maybe D needs a "copy" operator. For value types it would be a direct copy, for classes it would default to memberwise copy and be overridable. (Should it copy members using itself or using =?, ie shallow or deep copy? Not sure. Maybe _two_ operators ;-)
> I'd like <- if it wasn't such a parsing nightmare, #= or @= maybe?
> Sam
>
> PS is this like what Heron does? I haven't had a chance to look at it yet.

I think it would be nice of have a deep and shallow assignment, since we already have a deep and shallow comparison.   Parhaps something along those lines.

@= //Shallow
@== //Deep

-- 
-Anderson: http://badmama.com.au/~anderson/

>Maybe D needs a "copy" operator. For value types it would be a direct
>copy, for classes it would default to memberwise copy and be
>overridable. (Should it copy members using itself or using =?, ie
>shallow or deep copy? Not sure. Maybe _two_ operators ;-)
>I'd like <- if it wasn't such a parsing nightmare, #= or @= maybe?
>Sam
>
>PS is this like what Heron does? I haven't had a chance to look at it yet.

Well, in Heron you two different operators, one to copy the object, one to copy the reference itself.

Eiffel has maechanisms for flat and deep copying.

While it was 2/11/04 12:31 PM throughout the UK, Sam McCall sprinkled little black dots on a white screen, and they fell thus:

<snip>
> Maybe D needs a "copy" operator. For value types it would be a direct copy, for classes it would default to memberwise copy and be overridable. (Should it copy members using itself or using =?, ie shallow or deep copy? Not sure. Maybe _two_ operators ;-)
> I'd like <- if it wasn't such a parsing nightmare, #= or @= maybe?
> Sam

Even still, there are at least two ways that object copying could work:

- filling in the members of the destination object with the copied data (similar to C++) - would probably add unnecessary complications to both the D implementor and the D programmer.

- creating a copy as a new object (similar to Java clone, and D dup on things that support it) - wouldn't by itself solve the OP's problem without further complications.

And if we did implement a deep copy operator, we'd also need to think about our multiple references and circular data structures.

> PS is this like what Heron does? I haven't had a chance to look at it yet.

I see, another language that Foldoc still hasn't heard of.  Maybe I'll look at it when I get the time....

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c0d3ti$22u6$1@digitaldaemon.com...
> The = operator on objects has a specific meaning as far as D is concerned - to copy object references, not the objects (or parts thereof) themselves.
>
> I think the only reason C++ allows overloading of = is that variables _are_ objects, not just references to them.  Combining this with C++'s lack of GC, assignments sometimes need special handling.
>
> OTOH, in D, with its objects by reference and GC, being able to overload = was deemed pointless for anything but code obfuscation.

Most of the assignment operator overloading in C++ seems to be needed to just keep track of who owns the memory. So by using reference types coupled with GC, most of this just gets replaced with copying the reference itself. For example, given an array of class objects, the array's contents can be moved, sorted, shifted, etc., all without any need for overloaded assignments. Ditto for function parameters and return values. The references themselves just get moved about. There just doesn't seem to be any need for copying the entire contents of one class object into another pre-existing class object.

Sometimes, one does need to create a copy of a class object, and for that one can still write a copy constructor in D, but they just don't seem to be needed remotely as much as in C++.

Structs, being value objects, do get copied about. A copy is defined in D to be a bit copy. I've never been comfortable with any object in C++ that does something other than a bit copy when copied. Most of this other behavior stems from that old problem of trying to manage memory. Absent that, there doesn't seem to be a compelling rationale for allowing anything other than a bit copy.

What if you want your structs to really pass by value, or if you want to get consistent behavior with any template argument.

For my BigRational struct it passes by value if you use an int or a long, but it passes by reference if you use a Int class (or some Int struct with an array) in the template.  Likewise an assign is a deep copy with long, and a shallow copy with a class.

It would be nice to get consistent behavior no matter the template argument.

Walter wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:c0d3ti$22u6$1@digitaldaemon.com...
> 
>>The = operator on objects has a specific meaning as far as D is
>>concerned - to copy object references, not the objects (or parts
>>thereof) themselves.
>>
>>I think the only reason C++ allows overloading of = is that variables
>>_are_ objects, not just references to them.  Combining this with C++'s
>>lack of GC, assignments sometimes need special handling.
>>
>>OTOH, in D, with its objects by reference and GC, being able to overload
>>= was deemed pointless for anything but code obfuscation.
> 
> 
> Most of the assignment operator overloading in C++ seems to be needed to
> just keep track of who owns the memory. So by using reference types coupled
> with GC, most of this just gets replaced with copying the reference itself.
> For example, given an array of class objects, the array's contents can be
> moved, sorted, shifted, etc., all without any need for overloaded
> assignments. Ditto for function parameters and return values. The references
> themselves just get moved about. There just doesn't seem to be any need for
> copying the entire contents of one class object into another pre-existing
> class object.
> 
> Sometimes, one does need to create a copy of a class object, and for that
> one can still write a copy constructor in D, but they just don't seem to be
> needed remotely as much as in C++.
> 
> Structs, being value objects, do get copied about. A copy is defined in D to
> be a bit copy. I've never been comfortable with any object in C++ that does
> something other than a bit copy when copied. Most of this other behavior
> stems from that old problem of trying to manage memory. Absent that, there
> doesn't seem to be a compelling rationale for allowing anything other than a
> bit copy.
> 
>