View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2005
Re: How to bridge the gap between user defined types and built in types?
With respect to the established mathematical notation,

:= should by the identity assignment






In article <opspa0gry023k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>To get some idea of context you're best to read the entire thread, tho  
>it's a big one.. so, to make life easier I'm going to attempt to summarise  
>it. (if anyone has corrections, please make them)
>
>In essence Derek wanted to assign the value of an object with another. His  
>initial idea was to use an overload of the assingment operator, as is done  
>in C++.
>
>D does not allow you to overload the assignment operator, I believe,  
>because Walter dislikes the subtle behaviour this introduces, and in his  
>experience subtle bugs can arise out of it.
>
>Classes are references and assignment '=' does a reference assignment.  
>Overloading '=' to do a value assignment for a class would change this  
>behaviour.
>
>So, how to solve Dereks requirement of a value assignment for a reference  
>type.
>
>It occured to me that this was identical to a "deep copy" where the object  
>being assigned was the same type as the value being assigned.
>
>So, "to kill 2 birds with one stone" (AKA solve both problems at once) I  
>figured a value assignment operator was required. I remember someone  
>talking about ":=" and it's use in other languages, tho I've never used  
>them, so I suggested it.
>
>It also occured to me that we have "==" and "is" for value and identity  
>comparisons (albeit with exceptions - IMO sensible ones) and it therefore  
>makes sense to have ":=" and "=" for value and identity assignments  
>(interestingly with all the same exceptions as "==" and "is" operate  
>under).
>
>My take on "==" and "is" (for reference):
>
>1. "==" does value comparison.
>2. "is" does identity comparison.
>
>Exception to 1, a reference type with no defined method of comparison is  
>compared using identity. If identity is equal, value will be equal. If  
>identity is not equal then given no way to compare value one must assume  
>inequality or throw an exception. (D assumes inequality, an exception can  
>be thrown by coding it manually)
>
>Exception to 2, a value type. No 2 values types can compare equal in  
>identity. Technically this could be an error? However, D does a value  
>comparison. A lint program could catch and error on this. I see little  
>point and quite like the way "if (a is 5)" (where a is an 'int' or  
>similar) reads.
>
>How these exceptions apply to "=" and ":=":
>
>1. ":=" does value assignment
>2. "="  does identity assignment
>
>Exception to 1, a reference type with no defined method of assignment.  
>Best behaviour here would be an error IMO.
>
>Exception to 2, a value type. You cannot assign identity to a value type,  
>so you assign value (current D behaviour).
>
>So, as you can see the exceptions are parallel, the behvaiour of "=" need  
>not change, all that is added is ":=" and opAssign overloads for reference  
>types.
>
>Regan
>
>On Fri, 15 Apr 2005 21:00:25 +0400, Vladimir <kv11111@mail.ru> wrote:
>> TechnoZeus wrote:
>>
>>> Oops... my apologies, Vladimir.  I thought I was reading Ben's post.   
>>> Had
>>> clicked on it in the list, and somehow got yours... didn't notice the
>>> signature, until just as I clicked the "send" button.
>>>
>>> Sorry about the confusion.  Anyway... Thanks for the great idea  
>>> Vladimir.
>>> Please elaborate.
>>
>> Actually this is not my idea, look at the thread called opValue at the  
>> and
>> of discussion. But I really like this idea and think it's very important.
>> The only trouble is to convince Walter to allow this operator.
>>
>> For quick explanation, this it the extraction from that thread:
>>
>> ,--------------- Forwarded message (begin)
>>
>>  Subject: Re: opValue()
>>  From: Regan Heath <regan@netwin.co.nz>
>>  Date: Thu, 07 Apr 2005 05:34:52 +0400
>>  Newsgroup: digitalmars.D
>>
>>  On Thu, 07 Apr 2005 08:45:21 +1200, <brad@domain.invalid> wrote:
>>  > rter syntax:
>>  >>  class T { T opShlAssign(Foo c) { /*...*/ return this; } }
>>  >>  a<<=b; // almost like a=b, if you ask me
>>  >>  I guess in 99.99999% cases, shifting an object to left with another
>>  >> object doesn't make sense anyway, so the operator might as well get
>>  >> another use..
>>  >>   xs0
>>  >
>>  > Argh!  Surely not!  I thought one of the philosophies of D was that
>>  > operators should _always_ do what you expect.  The <<= operator should
>>  > always shift left & assign.
>>  >
>>  > Derek - am I right in saying that you want an assignment operator that
>>  > doesn't create a new object, but instead alters an existing one?  At  
>> the
>>  > moment, when you deal with objects/references, the = operator always
>>  > means "set this reference to this object".  I don't think that it  
>> makes
>>  > sense to overload this meaning, because you then end up with an  
>> operator
>>  > that in some cases does
>>  > "set this reference to this object" and in other cases
>>  > "alter the internal data layout of object A, based on the values in
>>  > object B"
>>  > And then you end up with a whole lot of special rules to try and
>>  > remember which assignment operator is applying.  Overwriting the
>>  > contents of an object when you really ment to assign to a new object
>>  > could ruin your day if you hold multiple references to the object you
>>  > are stomping on.
>>  >
>>  > I am in favour of having an operator that means "take object B, get  
>> some
>>  > values out of it and setup object A accordingly"
>> And if they're the same type, it could be used for a "deep-copy"?
>>  I think we can combine this casting concern with the deep-copy concern,
>>  they seem closely related to me.
>> > Something like
>>  > Foo a = new Foo ();
>>  > Bar b = new Bar ();
>>  > a <- b // which calls a.opConvert(b);
>>  >
>>  > I guess you could also end up with nasty
>>  > a = (new Foo())<- b;
>> It seems 'correct' if 'ugly', done in 2 steps looks nicer and incurs no
>>  additional penalty (that I can see).
>> a = new Foo();
>>  a <- b;
>> this operator is really a "copy RHS into LHS" operator, which implys that
>>  LHS must exists beforehand.
>>  Or using the "<-" operator could implicitly call new if the LHS is  
>> null...
>>  not sure how feasible that is.
>> > <- is probably not the operator to choose, probably hard to parse.  
>> Maybe
>>  > someone else can think of a good operator if this functionality is
>>  > required.
>> I agree, I think the main concern against this in Walters case was that
>>  implicit conversion when "=" is used can cause subtle behaviour and  
>> bugs.
>>  (correct me if I am wrong).
>> So, if a new operator was used, eg. ":=" or something then this concern
>>  vanishes, as "=" does what it currently does:
>>    - shallow copy for arrays.
>>    - reference assignment for classes etc
>>    - deep copy for value types
>> The new ":=" operator always means "copy RHS into LHS" AKA:
>>    - deep copy for arrays (provided items in array have deep-copy method
>>  defined)
>>    - deep copy for classes (provided class has deep-copy method defined)
>>    - same as "=" for value types.
>> Thoughts?
>> Regan
>>
>> `--------------- Forwarded message (end)
>>
>>
>>
>
April 20, 2005
Re: How to bridge the gap between user defined types and built in types?
Why?

TZ

"Christian Schüler" <Christian_member@pathlink.com> wrote in message news:d46omi$1hsn$1@digitaldaemon.com...
>
> With respect to the established mathematical notation,
>
> := should by the identity assignment
>
>
>
>
>
>
> In article <opspa0gry023k2f5@nrage.netwin.co.nz>, Regan Heath says...
> >
> >To get some idea of context you're best to read the entire thread, tho
> >it's a big one.. so, to make life easier I'm going to attempt to summarise
> >it. (if anyone has corrections, please make them)
> >
> >In essence Derek wanted to assign the value of an object with another. His
> >initial idea was to use an overload of the assingment operator, as is done
> >in C++.
> >
> >D does not allow you to overload the assignment operator, I believe,
> >because Walter dislikes the subtle behaviour this introduces, and in his
> >experience subtle bugs can arise out of it.
> >
> >Classes are references and assignment '=' does a reference assignment.
> >Overloading '=' to do a value assignment for a class would change this
> >behaviour.
> >
> >So, how to solve Dereks requirement of a value assignment for a reference
> >type.
> >
> >It occured to me that this was identical to a "deep copy" where the object
> >being assigned was the same type as the value being assigned.
> >
> >So, "to kill 2 birds with one stone" (AKA solve both problems at once) I
> >figured a value assignment operator was required. I remember someone
> >talking about ":=" and it's use in other languages, tho I've never used
> >them, so I suggested it.
> >
> >It also occured to me that we have "==" and "is" for value and identity
> >comparisons (albeit with exceptions - IMO sensible ones) and it therefore
> >makes sense to have ":=" and "=" for value and identity assignments
> >(interestingly with all the same exceptions as "==" and "is" operate
> >under).
> >
> >My take on "==" and "is" (for reference):
> >
> >1. "==" does value comparison.
> >2. "is" does identity comparison.
> >
> >Exception to 1, a reference type with no defined method of comparison is
> >compared using identity. If identity is equal, value will be equal. If
> >identity is not equal then given no way to compare value one must assume
> >inequality or throw an exception. (D assumes inequality, an exception can
> >be thrown by coding it manually)
> >
> >Exception to 2, a value type. No 2 values types can compare equal in
> >identity. Technically this could be an error? However, D does a value
> >comparison. A lint program could catch and error on this. I see little
> >point and quite like the way "if (a is 5)" (where a is an 'int' or
> >similar) reads.
> >
> >How these exceptions apply to "=" and ":=":
> >
> >1. ":=" does value assignment
> >2. "="  does identity assignment
> >
> >Exception to 1, a reference type with no defined method of assignment.
> >Best behaviour here would be an error IMO.
> >
> >Exception to 2, a value type. You cannot assign identity to a value type,
> >so you assign value (current D behaviour).
> >
> >So, as you can see the exceptions are parallel, the behvaiour of "=" need
> >not change, all that is added is ":=" and opAssign overloads for reference
> >types.
> >
> >Regan
> >
> >On Fri, 15 Apr 2005 21:00:25 +0400, Vladimir <kv11111@mail.ru> wrote:
> >> TechnoZeus wrote:
> >>
> >>> Oops... my apologies, Vladimir.  I thought I was reading Ben's post.
> >>> Had
> >>> clicked on it in the list, and somehow got yours... didn't notice the
> >>> signature, until just as I clicked the "send" button.
> >>>
> >>> Sorry about the confusion.  Anyway... Thanks for the great idea
> >>> Vladimir.
> >>> Please elaborate.
> >>
> >> Actually this is not my idea, look at the thread called opValue at the
> >> and
> >> of discussion. But I really like this idea and think it's very important.
> >> The only trouble is to convince Walter to allow this operator.
> >>
> >> For quick explanation, this it the extraction from that thread:
> >>
> >> ,--------------- Forwarded message (begin)
> >>
> >>  Subject: Re: opValue()
> >>  From: Regan Heath <regan@netwin.co.nz>
> >>  Date: Thu, 07 Apr 2005 05:34:52 +0400
> >>  Newsgroup: digitalmars.D
> >>
> >>  On Thu, 07 Apr 2005 08:45:21 +1200, <brad@domain.invalid> wrote:
> >>  > rter syntax:
> >>  >>  class T { T opShlAssign(Foo c) { /*...*/ return this; } }
> >>  >>  a<<=b; // almost like a=b, if you ask me
> >>  >>  I guess in 99.99999% cases, shifting an object to left with another
> >>  >> object doesn't make sense anyway, so the operator might as well get
> >>  >> another use..
> >>  >>   xs0
> >>  >
> >>  > Argh!  Surely not!  I thought one of the philosophies of D was that
> >>  > operators should _always_ do what you expect.  The <<= operator should
> >>  > always shift left & assign.
> >>  >
> >>  > Derek - am I right in saying that you want an assignment operator that
> >>  > doesn't create a new object, but instead alters an existing one?  At
> >> the
> >>  > moment, when you deal with objects/references, the = operator always
> >>  > means "set this reference to this object".  I don't think that it
> >> makes
> >>  > sense to overload this meaning, because you then end up with an
> >> operator
> >>  > that in some cases does
> >>  > "set this reference to this object" and in other cases
> >>  > "alter the internal data layout of object A, based on the values in
> >>  > object B"
> >>  > And then you end up with a whole lot of special rules to try and
> >>  > remember which assignment operator is applying.  Overwriting the
> >>  > contents of an object when you really ment to assign to a new object
> >>  > could ruin your day if you hold multiple references to the object you
> >>  > are stomping on.
> >>  >
> >>  > I am in favour of having an operator that means "take object B, get
> >> some
> >>  > values out of it and setup object A accordingly"
> >> And if they're the same type, it could be used for a "deep-copy"?
> >>  I think we can combine this casting concern with the deep-copy concern,
> >>  they seem closely related to me.
> >> > Something like
> >>  > Foo a = new Foo ();
> >>  > Bar b = new Bar ();
> >>  > a <- b // which calls a.opConvert(b);
> >>  >
> >>  > I guess you could also end up with nasty
> >>  > a = (new Foo())<- b;
> >> It seems 'correct' if 'ugly', done in 2 steps looks nicer and incurs no
> >>  additional penalty (that I can see).
> >> a = new Foo();
> >>  a <- b;
> >> this operator is really a "copy RHS into LHS" operator, which implys that
> >>  LHS must exists beforehand.
> >>  Or using the "<-" operator could implicitly call new if the LHS is
> >> null...
> >>  not sure how feasible that is.
> >> > <- is probably not the operator to choose, probably hard to parse.
> >> Maybe
> >>  > someone else can think of a good operator if this functionality is
> >>  > required.
> >> I agree, I think the main concern against this in Walters case was that
> >>  implicit conversion when "=" is used can cause subtle behaviour and
> >> bugs.
> >>  (correct me if I am wrong).
> >> So, if a new operator was used, eg. ":=" or something then this concern
> >>  vanishes, as "=" does what it currently does:
> >>    - shallow copy for arrays.
> >>    - reference assignment for classes etc
> >>    - deep copy for value types
> >> The new ":=" operator always means "copy RHS into LHS" AKA:
> >>    - deep copy for arrays (provided items in array have deep-copy method
> >>  defined)
> >>    - deep copy for classes (provided class has deep-copy method defined)
> >>    - same as "=" for value types.
> >> Thoughts?
> >> Regan
> >>
> >> `--------------- Forwarded message (end)
> >>
> >>
> >>
> >
>
>
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
I am soliticting help from the senior members of the NG.  As I mention 
in another thread, I would like to call a weigh in on this issue.
If I get 3 senior members (I mention specific names in the Walter Weigh 
In thread, but if I have missed anyone please speak up) saying that 
introducing ":=" as a deepcopy operator is a good idea, then I will 
summerize this thread and rename it to
"Walter Weigh In: How to bridge the gap between user defined types and 
built in types"

Can I please have sanction from at least three of the more senior people 
here.

Thanks
Brad
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
I'll do one better than that.

TZ

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d46qs6$1jpt$1@digitaldaemon.com...
> I am soliticting help from the senior members of the NG.  As I mention
> in another thread, I would like to call a weigh in on this issue.
> If I get 3 senior members (I mention specific names in the Walter Weigh
> In thread, but if I have missed anyone please speak up) saying that
> introducing ":=" as a deepcopy operator is a good idea, then I will
> summerize this thread and rename it to
> "Walter Weigh In: How to bridge the gap between user defined types and
> built in types"
>
> Can I please have sanction from at least three of the more senior people
> here.
>
> Thanks
> Brad
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
Just as I was expecting that a google search on "mathematical identity" would
turn up loads of examples, it fails on me...

The proper symbol for identity is really U+2261, "identity", a = with 3 dashes.

Besides that, I recall := being used in mathematical context for expressing
identity as opposed to equal values, which is what = stands for.





In article <d46pk7$1ii7$1@digitaldaemon.com>, TechnoZeus says...
>
>Why?
>
>TZ
>
>"Christian Schüler" <Christian_member@pathlink.com> wrote in message news:d46omi$1hsn$1@digitaldaemon.com...
>>
>> With respect to the established mathematical notation,
>>
>> := should by the identity assignment
>>
>>
>>
>>
>>
>>
>> In article <opspa0gry023k2f5@nrage.netwin.co.nz>, Regan Heath says...
>> >
>> >To get some idea of context you're best to read the entire thread, tho
>> >it's a big one.. so, to make life easier I'm going to attempt to summarise
>> >it. (if anyone has corrections, please make them)
>> >
>> >In essence Derek wanted to assign the value of an object with another. His
>> >initial idea was to use an overload of the assingment operator, as is done
>> >in C++.
>> >
>> >D does not allow you to overload the assignment operator, I believe,
>> >because Walter dislikes the subtle behaviour this introduces, and in his
>> >experience subtle bugs can arise out of it.
>> >
>> >Classes are references and assignment '=' does a reference assignment.
>> >Overloading '=' to do a value assignment for a class would change this
>> >behaviour.
>> >
>> >So, how to solve Dereks requirement of a value assignment for a reference
>> >type.
>> >
>> >It occured to me that this was identical to a "deep copy" where the object
>> >being assigned was the same type as the value being assigned.
>> >
>> >So, "to kill 2 birds with one stone" (AKA solve both problems at once) I
>> >figured a value assignment operator was required. I remember someone
>> >talking about ":=" and it's use in other languages, tho I've never used
>> >them, so I suggested it.
>> >
>> >It also occured to me that we have "==" and "is" for value and identity
>> >comparisons (albeit with exceptions - IMO sensible ones) and it therefore
>> >makes sense to have ":=" and "=" for value and identity assignments
>> >(interestingly with all the same exceptions as "==" and "is" operate
>> >under).
>> >
>> >My take on "==" and "is" (for reference):
>> >
>> >1. "==" does value comparison.
>> >2. "is" does identity comparison.
>> >
>> >Exception to 1, a reference type with no defined method of comparison is
>> >compared using identity. If identity is equal, value will be equal. If
>> >identity is not equal then given no way to compare value one must assume
>> >inequality or throw an exception. (D assumes inequality, an exception can
>> >be thrown by coding it manually)
>> >
>> >Exception to 2, a value type. No 2 values types can compare equal in
>> >identity. Technically this could be an error? However, D does a value
>> >comparison. A lint program could catch and error on this. I see little
>> >point and quite like the way "if (a is 5)" (where a is an 'int' or
>> >similar) reads.
>> >
>> >How these exceptions apply to "=" and ":=":
>> >
>> >1. ":=" does value assignment
>> >2. "="  does identity assignment
>> >
>> >Exception to 1, a reference type with no defined method of assignment.
>> >Best behaviour here would be an error IMO.
>> >
>> >Exception to 2, a value type. You cannot assign identity to a value type,
>> >so you assign value (current D behaviour).
>> >
>> >So, as you can see the exceptions are parallel, the behvaiour of "=" need
>> >not change, all that is added is ":=" and opAssign overloads for reference
>> >types.
>> >
>> >Regan
>> >
>> >On Fri, 15 Apr 2005 21:00:25 +0400, Vladimir <kv11111@mail.ru> wrote:
>> >> TechnoZeus wrote:
>> >>
>> >>> Oops... my apologies, Vladimir.  I thought I was reading Ben's post.
>> >>> Had
>> >>> clicked on it in the list, and somehow got yours... didn't notice the
>> >>> signature, until just as I clicked the "send" button.
>> >>>
>> >>> Sorry about the confusion.  Anyway... Thanks for the great idea
>> >>> Vladimir.
>> >>> Please elaborate.
>> >>
>> >> Actually this is not my idea, look at the thread called opValue at the
>> >> and
>> >> of discussion. But I really like this idea and think it's very important.
>> >> The only trouble is to convince Walter to allow this operator.
>> >>
>> >> For quick explanation, this it the extraction from that thread:
>> >>
>> >> ,--------------- Forwarded message (begin)
>> >>
>> >>  Subject: Re: opValue()
>> >>  From: Regan Heath <regan@netwin.co.nz>
>> >>  Date: Thu, 07 Apr 2005 05:34:52 +0400
>> >>  Newsgroup: digitalmars.D
>> >>
>> >>  On Thu, 07 Apr 2005 08:45:21 +1200, <brad@domain.invalid> wrote:
>> >>  > rter syntax:
>> >>  >>  class T { T opShlAssign(Foo c) { /*...*/ return this; } }
>> >>  >>  a<<=b; // almost like a=b, if you ask me
>> >>  >>  I guess in 99.99999% cases, shifting an object to left with another
>> >>  >> object doesn't make sense anyway, so the operator might as well get
>> >>  >> another use..
>> >>  >>   xs0
>> >>  >
>> >>  > Argh!  Surely not!  I thought one of the philosophies of D was that
>> >>  > operators should _always_ do what you expect.  The <<= operator should
>> >>  > always shift left & assign.
>> >>  >
>> >>  > Derek - am I right in saying that you want an assignment operator that
>> >>  > doesn't create a new object, but instead alters an existing one?  At
>> >> the
>> >>  > moment, when you deal with objects/references, the = operator always
>> >>  > means "set this reference to this object".  I don't think that it
>> >> makes
>> >>  > sense to overload this meaning, because you then end up with an
>> >> operator
>> >>  > that in some cases does
>> >>  > "set this reference to this object" and in other cases
>> >>  > "alter the internal data layout of object A, based on the values in
>> >>  > object B"
>> >>  > And then you end up with a whole lot of special rules to try and
>> >>  > remember which assignment operator is applying.  Overwriting the
>> >>  > contents of an object when you really ment to assign to a new object
>> >>  > could ruin your day if you hold multiple references to the object you
>> >>  > are stomping on.
>> >>  >
>> >>  > I am in favour of having an operator that means "take object B, get
>> >> some
>> >>  > values out of it and setup object A accordingly"
>> >> And if they're the same type, it could be used for a "deep-copy"?
>> >>  I think we can combine this casting concern with the deep-copy concern,
>> >>  they seem closely related to me.
>> >> > Something like
>> >>  > Foo a = new Foo ();
>> >>  > Bar b = new Bar ();
>> >>  > a <- b // which calls a.opConvert(b);
>> >>  >
>> >>  > I guess you could also end up with nasty
>> >>  > a = (new Foo())<- b;
>> >> It seems 'correct' if 'ugly', done in 2 steps looks nicer and incurs no
>> >>  additional penalty (that I can see).
>> >> a = new Foo();
>> >>  a <- b;
>> >> this operator is really a "copy RHS into LHS" operator, which implys that
>> >>  LHS must exists beforehand.
>> >>  Or using the "<-" operator could implicitly call new if the LHS is
>> >> null...
>> >>  not sure how feasible that is.
>> >> > <- is probably not the operator to choose, probably hard to parse.
>> >> Maybe
>> >>  > someone else can think of a good operator if this functionality is
>> >>  > required.
>> >> I agree, I think the main concern against this in Walters case was that
>> >>  implicit conversion when "=" is used can cause subtle behaviour and
>> >> bugs.
>> >>  (correct me if I am wrong).
>> >> So, if a new operator was used, eg. ":=" or something then this concern
>> >>  vanishes, as "=" does what it currently does:
>> >>    - shallow copy for arrays.
>> >>    - reference assignment for classes etc
>> >>    - deep copy for value types
>> >> The new ":=" operator always means "copy RHS into LHS" AKA:
>> >>    - deep copy for arrays (provided items in array have deep-copy method
>> >>  defined)
>> >>    - deep copy for classes (provided class has deep-copy method defined)
>> >>    - same as "=" for value types.
>> >> Thoughts?
>> >> Regan
>> >>
>> >> `--------------- Forwarded message (end)
>> >>
>> >>
>> >>
>> >
>>
>>
>
>
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
Christian Schüler wrote:
> Just as I was expecting that a google search on "mathematical identity" would
> turn up loads of examples, it fails on me...
> 
> The proper symbol for identity is really U+2261, "identity", a = with 3 dashes.
> 
> Besides that, I recall := being used in mathematical context for expressing
> identity as opposed to equal values, which is what = stands for.
> 
From a practical programmers point of view, I don't think that the 
operator we choose is particularly relevant.  I think that ":=" was 
adopted because it has the "=" sign in it, it looks like an assignment 
operation, and Pascal programmers will be familiar with it.
I think it would be folly to try to use "=" for deep copy, and ":=" for 
what we currently use "=" for.
Anyhow - the real core of the issue is that many of us feel a "deep 
copy" operator makes sense.

Brad
April 21, 2005
[Suggestion] [Walter] Re: How to bridge the gap between user defined types and built in types?
Anders mentioned the addition of a ":=" operator on April 12th,
and then there is this one,
to which I am posting a reply,
and the discussion has resulted in what looks suspiciously like nearly unanimous agreement...
so as has been pointed out more than once,
it's time to ask Walter to have a look at it.

Walter: Please consider the addition of ":=" as a vlaue assignment operator.

What's meant by that, is while "=" would continue to function "as is" there would be the option of using ":=" to represent assignment of value regardless of whether dealing with value types or reverence types.

In cases where assigning value can't be done, ":=" would produce an error rather than assign by identity.  This would allow unambiguous source code, and would also point out any places where there may be a need to add a value assignment specifically.

Please give us some indication of what you think on this matter.  Many of us would very much like to see this implemented, and feel that it would be very beneficial.

Donald A. Kronos, PhD. - TechnoZeus


"Vladimir" <kv11111@mail.ru> wrote in message news:d3o2ho$al$1@digitaldaemon.com...
> BTW, the simple workaround about general templates. Inside template one
> could write
> a=b+0;
> instead of
> a=b;
> to emulate assignment by value.
>
> But in my opinion having something like ":=" operator is much more
> convenient.
>
> -- 
>           Vladimir
April 21, 2005
Comments on the proposed value assignment opperator [:=]
I'm inviting anyone who wants to summarize their thoughts or comments on the proposed ":=" assignment opperator to do so as a reply to this post...
to save Walter the time necessary to otherwise search for such comments.

TechnoZeus
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
TechnoZeus wrote:
> I'm inviting anyone who wants to summarize their thoughts or comments on the proposed ":=" assignment opperator to do so as a reply to this post...
> to save Walter the time necessary to otherwise search for such comments.
> 
> TechnoZeus
> 
> 
My only comment is thus:
The flexibility of the ":=" operator is twofold if it calls an 
"opAssign" function when used with LHS being a class.  Calling opAssign 
(or some other name) because then you not only have the deep copy 
ability, but you can cast/convert from one class type to another.
ie
Foo a = new Foo();
Foo b = new Foo();
Bar c = new Bar();
a := b; // calls Foo.opAssign(Foo rhs);
a := c; // calls Foo.opAssign(Bar rhs);

Also, array.dup can now go away.

Brad
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
Cool.  Hadn't thought of that.  :)

Now I'm wondering how many other "unexpected" potential benefits there might be.

Other comments?

TZ

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d46u5v$1mi8$1@digitaldaemon.com...
> TechnoZeus wrote:
> > I'm inviting anyone who wants to summarize their thoughts or comments on the proposed ":=" assignment opperator to do so as a reply to this post...
> > to save Walter the time necessary to otherwise search for such comments.
> >
> > TechnoZeus
> >
> >
> My only comment is thus:
> The flexibility of the ":=" operator is twofold if it calls an
> "opAssign" function when used with LHS being a class.  Calling opAssign
> (or some other name) because then you not only have the deep copy
> ability, but you can cast/convert from one class type to another.
> ie
> Foo a = new Foo();
> Foo b = new Foo();
> Bar c = new Bar();
> a := b; // calls Foo.opAssign(Foo rhs);
> a := c; // calls Foo.opAssign(Bar rhs);
>
> Also, array.dup can now go away.
>
> Brad
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home