April 21, 2005 Re: Comments on the proposed value assignment opperator [:=] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Beveridge |
> 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to TechnoZeus | >> > 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 [:=] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir | 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 [:=] | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | 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 [:=] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 [:=] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir | "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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to TechnoZeus | "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 :-) |
Copyright © 1999-2021 by the D Language Foundation