View mode: basic / threaded / horizontal-split · Log in · Help
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
> 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.

array.dup would still be needed (like any dup property) in expressions that 
don't have any assignment. For example "return array.dup;"
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
>> > There are obviously advantages to adding a := operator for value
>> > assignments, and I have yet to hear a down side to it.
>>
>> http://www.digitalmars.com/d/faq.html#assignmentoverloading
>
> Why the link to information about assignment overloading?

That's what this discussion on := and opAssign are about. Walter has already 
thought about overloading assignment and it has come up before on the 
newsgroup (I actually found that link during a quick search of the 
archives).
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
>
>About the template problem: I'd prefer to look into something like extending 
>".dup" to all types rather than invent a new operator. 

Ben, thank you.  You took the words right out of my mouth. :)

For classes, there's no need to make this a formal 'operator'.  It could merely
be added to Object as a shallow copy (return this;) and then overridden in any
class where it's needed.  

So really, all that's needed is a 'dup' property for scalars.  The rest is up to
the developer.


class Foobar{
public Foobar dup(){
return this; // or a copy
}
}

void main(){
Foobar a,b;
a = new Foobar();
b = a.dup; // custom ('deep') copy

int c,d;
c = d.dup; // value-copy: allowed for consistency

int[] e,f
e = f.dup; // old hat
}

The above folds into templates, extremely well:

template valueOf(T){ T valueOf(T x){ return x.dup; } }

.. where 'T' can be, well, anything.  I'll add that the above is also
*impossible* with ':=' and would require a temporary varible to work.  Thus, it
would be less flexible (and probably useful IMO).

There's absolutely no need for an additional operator like ':='.

- EricAnderton at yahoo
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
Ben Hinkle wrote:

>>> > There are obviously advantages to adding a := operator for value
>>> > assignments, and I have yet to hear a down side to it.
>>>
>>> http://www.digitalmars.com/d/faq.html#assignmentoverloading
>>
>> Why the link to information about assignment overloading?
> 
> That's what this discussion on := and opAssign are about. Walter has
> already thought about overloading assignment and it has come up before on
> the newsgroup (I actually found that link during a quick search of the
> archives).
This discussion is not about opAssign overloading, but about problems when
writing general templates that must work with classes as well as with
fundamental types.

Addition of := operator may require making it overloadable because of
external resource allocation (not only memory allocation but also opened
files, DB connections and so on).

Allowing := overloading also will solve casting problem (for example ability
to write BigInt class in such way that code { BigInt i; i:=100; } can be
compiled), but this is just side-effect.

But again, even adding this operator will not solve the whole problem with
general templates.


-- 
         Vladimir
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
Vladimir wrote:

> /* Class for calculation some difficult function and caching result */
> /* Suppose reverse function is easy to calculate */
> class SomeFunction(T) {
>         T _cached_val;
> 
>         T calculate(T input) {
>                 /* if T is class we have seg-v here at first invocation
>                  * because _cached_val is null */
>                 if(input == calculate_reverse(_cached_val))
>
> 2. reference-type variable are always initialized to null, while
value-type can't be null

One of possible solutions for this is to add static init property for
classes:

class A {
       /* example */
       static A init = new A(0,0);  /* evaluated only once */

       /* default is: static A init = null; } */
}

and then treat expression
A a; as A a = A.init;
(this is exactly the same as with fundamental types)

so
A a; A b;
if((a is b) and (a is A.init)) writef(" true ");
will print "true"

-- 
         Vladimir
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
pragma wrote:

> In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>About the template problem: I'd prefer to look into something like
>>extending ".dup" to all types rather than invent a new operator.
> 
> Ben, thank you.  You took the words right out of my mouth. :)
> 
> For classes, there's no need to make this a formal 'operator'.  It could
> merely be added to Object as a shallow copy (return this;) and then
> overridden in any class where it's needed.
> 
> So really, all that's needed is a 'dup' property for scalars.  The rest is
> up to the developer.
> 
> 
> class Foobar{
> public Foobar dup(){
> return this; // or a copy
> }
> }
> 
> void main(){
> Foobar a,b;
> a = new Foobar();
> b = a.dup; // custom ('deep') copy
> 
> int c,d;
> c = d.dup; // value-copy: allowed for consistency
> 
> int[] e,f
> e = f.dup; // old hat
> }
> 
> The above folds into templates, extremely well:
> 
> template valueOf(T){ T valueOf(T x){ return x.dup; } }
> 
> .. where 'T' can be, well, anything.  I'll add that the above is also
> *impossible* with ':=' and would require a temporary varible to work. 
> Thus, it would be less flexible (and probably useful IMO).
> 
> There's absolutely no need for an additional operator like ':='.
Formally you are right, but always typing a=b.dup is not convenient and can
be forgotten, especially when one tries to convert non-template function to
template.
May be we can add ':' unary operator which in expression :a works exactly
like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning
from function this will look like { return :a; }.

-- 
         Vladimir
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
In article <d48gt8$8ao$1@digitaldaemon.com>, Vladimir says...
>
>May be we can add ':' unary operator which in expression :a works exactly
>like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning
>from function this will look like { return :a; }.

The only wart here is that you'll run into small problems with ':' when
evaluating the ternary '?' operator:

foo() ? bar() : a; // what was meant here?  (value-of or ternary else)

.. but that's strictly a matter of operator precedence.  I for one, don't find
it as readable.

Not that I think it's a good idea, but you could use something like '@' to mean
'value-of' (which would be akin to '&' meaning 'address-of').

{ return @a; }

This isn't too bad, but it still lands us in "create a new operator territory".


I still think .dup() is the way to go.

-EricAnderton at yahoo
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
It's a big thread... that might have been in it somewhere.
This branch of it deals with adding ":=" as a separate operator in addition to the "=" operator,
and having ":=" act as a value assignment operator such that...
a := b;
anways results in (a == b) being true, but never makes (a is b) become true.

Not related to overloading the "=" operator.

TZ

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d48dc2$54g$1@digitaldaemon.com...
> >> > There are obviously advantages to adding a := operator for value
> >> > assignments, and I have yet to hear a down side to it.
> >>
> >> http://www.digitalmars.com/d/faq.html#assignmentoverloading
> >
> > Why the link to information about assignment overloading?
>
> That's what this discussion on := and opAssign are about. Walter has already
> thought about overloading assignment and it has come up before on the
> newsgroup (I actually found that link during a quick search of the
> archives).
>
>
April 21, 2005
Re: Comments on the proposed value assignment opperator [:=]
"Vladimir" <kv11111@mail.ru> wrote in message news:d48gt8$8ao$1@digitaldaemon.com...
> pragma wrote:
>
> > In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
> >>
> >>About the template problem: I'd prefer to look into something like
> >>extending ".dup" to all types rather than invent a new operator.
> >
> > Ben, thank you.  You took the words right out of my mouth. :)
> >
> > For classes, there's no need to make this a formal 'operator'.  It could
> > merely be added to Object as a shallow copy (return this;) and then
> > overridden in any class where it's needed.
> >
> > So really, all that's needed is a 'dup' property for scalars.  The rest is
> > up to the developer.
> >
> >
> > class Foobar{
> > public Foobar dup(){
> > return this; // or a copy
> > }
> > }
> >
> > void main(){
> > Foobar a,b;
> > a = new Foobar();
> > b = a.dup; // custom ('deep') copy
> >
> > int c,d;
> > c = d.dup; // value-copy: allowed for consistency
> >
> > int[] e,f
> > e = f.dup; // old hat
> > }
> >
> > The above folds into templates, extremely well:
> >
> > template valueOf(T){ T valueOf(T x){ return x.dup; } }
> >
> > .. where 'T' can be, well, anything.  I'll add that the above is also
> > *impossible* with ':=' and would require a temporary varible to work.
> > Thus, it would be less flexible (and probably useful IMO).
> >
> > There's absolutely no need for an additional operator like ':='.
> Formally you are right, but always typing a=b.dup is not convenient and can
> be forgotten, especially when one tries to convert non-template function to
> template.
> May be we can add ':' unary operator which in expression :a works exactly
> like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning
> from function this will look like { return :a; }.
>
> -- 
>           Vladimir

Correct me if I'm mistaken, but I think what you are saying only takes reference types into account.  The idea here is to get away from the risk of code failing to work when value types and reference types inevitably get confused.

There is, for example, not much sense to the following code...

int a = 5.dup;
int b;
int c;
b = a.dup + 7.dup;
c = b.dup;

Of course, this is an extreme case, but it is meant to illustrate a point.

If the programmer wants to be sure that they are assigning values, and not changing the address of somehting, then the ":=" operator would be used...

int a := 5;
int b;
int c;
b := a+7;
c := b;

No ambiguity there.  Notice that with this convention, one would know what "a := b" is supposed to do,
even without knowing what "a" and "b" represent.  The same can not be said of "a = b" in D.

TZ
April 21, 2005
Re: How to bridge the gap between user defined types and built in types?
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message 
news:d48iic$9se$1@digitaldaemon.com...
> It's a big thread... that might have been in it somewhere.
> This branch of it deals with adding ":=" as a separate operator in 
> addition to the "=" operator,
> and having ":=" act as a value assignment operator such that...
> a := b;
> anways results in (a == b) being true, but never makes (a is b) become 
> true.
>
> Not related to overloading the "=" operator.
>
> TZ

hehe. Sorry but it sounds funny to say an operator called := with overload 
opAssign is not related to overloading assignment. I would bet no matter 
what the symbol is and the overload name Walter's objections would still 
apply.

ps - I should have asked you to do my taxes :-)
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home