www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why to have properties to sort or duplicate arrays ?

reply =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> writes:
Hello,
To me, reading a field or a property should not modify the object.
The problem is that just an access to the properties 'reverse' or 'sort' are
modifying my array. These 2 properties should be method instead.

I think that the property 'dup' should be a method too, because 'dup' is not a
value of my Array object, it does something.
Jan 27 2007
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Pierre Reniť wrote:
 Hello,
 To me, reading a field or a property should not modify the object.
 The problem is that just an access to the properties 'reverse' or 'sort' are
modifying my array. These 2 properties should be method instead.
 
 I think that the property 'dup' should be a method too, because 'dup' is not a
value of my Array object, it does something.

Well, in D, properties are just normal methods.
Jan 27 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Hasan Aljudy wrote:
 
 
 Pierre Reniť wrote:
 Hello,
 To me, reading a field or a property should not modify the object.
 The problem is that just an access to the properties 'reverse' or 
 'sort' are modifying my array. These 2 properties should be method 
 instead.

 I think that the property 'dup' should be a method too, because 'dup' 
 is not a value of my Array object, it does something.

Well, in D, properties are just normal methods.

Which allows one to write nifty code like: writefln = 5 Yay. Not a big priority, but I do wish there were a way to specify which functions should be treated as properties. --bb
Jan 27 2007
prev sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Sat, 27 Jan 2007 19:18:32 -0500, Hasan Aljudy <hasan.aljudy gmail.com>  
wrote:
  I think that the property 'dup' should be a method too, because 'dup'  
 is not a value of my Array object, it does something.

Well, in D, properties are just normal methods.

Except these are magic properties and can't be called like functions, even though most of us prefer to call these ones as functions and not properties. However, this has been known for along time.
Jan 27 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 27 Jan 2007 18:00:10 -0500, Pierre Renié wrote:

 Hello,
 To me, reading a field or a property should not modify the object.
 The problem is that just an access to the properties 'reverse' 
 or 'sort' are modifying my array. These 2 properties should be
 method instead.
 
 I think that the property 'dup' should be a method too, because
 'dup' is not a value of my Array object, it does something.

Yes, this is a significant design mistake that has always been with us. I suspect it came about with the desire to make properties easy to create and use, but as a consequence, D properties aren't as useful as they could be. They are certainly a good thing but still not as good as they could have been. I believe that a 'get' Property should return a value without changing the entity that owns the value. I don't have an issue with the .dup property in this regard as it returns a copy of the entity; however it is not built-in to all datatypes, just arrays. But .sort and .reverse should just return a copy of the data, sorted or reversed respectively. I'm pretty sure that Walter will not be changing this or improving the Property concept any time soon though. So use this idiom instead ... (sorted_data = data.dup).sort; (reversed_data = data.dup).reverse; -- Derek Parnell
Jan 27 2007
next sibling parent reply =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> writes:
Derek Parnell Wrote:

 On Sat, 27 Jan 2007 18:00:10 -0500, Pierre Renié wrote:
 
 Hello,
 To me, reading a field or a property should not modify the object.
 The problem is that just an access to the properties 'reverse' 
 or 'sort' are modifying my array. These 2 properties should be
 method instead.
 
 I think that the property 'dup' should be a method too, because
 'dup' is not a value of my Array object, it does something.

Yes, this is a significant design mistake that has always been with us. I suspect it came about with the desire to make properties easy to create and use, but as a consequence, D properties aren't as useful as they could be. They are certainly a good thing but still not as good as they could have been. I believe that a 'get' Property should return a value without changing the entity that owns the value. I don't have an issue with the .dup property in this regard as it returns a copy of the entity; however it is not built-in to all datatypes, just arrays. But .sort and .reverse should just return a copy of the data, sorted or reversed respectively. I'm pretty sure that Walter will not be changing this or improving the Property concept any time soon though. So use this idiom instead ... (sorted_data = data.dup).sort; (reversed_data = data.dup).reverse; -- Derek Parnell

I don't think there is a need to change the property concept. Just deprecate the properties 'sort', 'reverse' and 'dup', and create methods instead.
Jan 28 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Pierre Reniť wrote:
 I don't think there is a need to change the property concept. Just deprecate
the properties 'sort', 'reverse' and 'dup', and create methods instead.

*All* functions and methods in D that take zero or 1 arguments act like properties. So just making 'sort' a method wouldn't change the fact that: array.sort would still be a valid expression that mutates the array. It would just make it so that array.sort() would *also* be valid syntax. [But I do agree that sort() should at least be valid syntax for those who don't want to write code that looks like the above.] ---------- import std.stdio; void foo() { writefln("hey I think I'm a property") } void foo(int x) { writefln("I think I'm a property too. And now I should be ", x); } void main() { foo; foo = 10; }
Jan 28 2007
prev sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
Derek Parnell wrote:
 On Sat, 27 Jan 2007 18:00:10 -0500, Pierre Renié wrote:
 
 Hello,
 To me, reading a field or a property should not modify the object.
 The problem is that just an access to the properties 'reverse' 
 or 'sort' are modifying my array. These 2 properties should be
 method instead.

 I think that the property 'dup' should be a method too, because
 'dup' is not a value of my Array object, it does something.

Yes, this is a significant design mistake that has always been with us. I suspect it came about with the desire to make properties easy to create and use, but as a consequence, D properties aren't as useful as they could be. They are certainly a good thing but still not as good as they could have been. I believe that a 'get' Property should return a value without changing the entity that owns the value. I don't have an issue with the .dup property in this regard as it returns a copy of the entity; however it is not built-in to all datatypes, just arrays. But .sort and .reverse should just return a copy of the data, sorted or reversed respectively. I'm pretty sure that Walter will not be changing this or improving the Property concept any time soon though. So use this idiom instead ... (sorted_data = data.dup).sort; (reversed_data = data.dup).reverse;

A functional programming language would probably do that but personally I prefer the in-place sort. The majority of the time, I would just have to assign the sorted version back over the original, which means I've done a copy to a heap allocated array for no benefit. In the few cases that I need a copy, I can use a dup as you describe. Another problem with returning a copy of the data, is that static arrays like int[5] would return a dynamic array, which would require awkward syntax: int[5] foo; // fill foo // unnecessary copy, allocation, gc collection int[] f2 = foo.sort(); // another unnecessary copy foo[] = f2[]; Kevin
Jan 28 2007