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 next 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
prev sibling parent reply renoX <renosky free.fr> writes:
Pierre Reniť Wrote:
 Hello,
 To me, reading a field or a property should not modify the object.
That's debatable, I remember an example of complex Class in a book which memorized the attributes when asked to convert say from x,y to length,angle.
 The problem is that just an access to the properties 'reverse' or 'sort' are
modifying my array. These 2 properties should be method instead.
IMHO that's not the real problem, the real problem is looking at the function name, you have no clue whether they do it in place or functional style. What I would prefer is that the name or reverse and sort indicate that they are modifying the array: like in Ruby we would have sort! and sort, sort! doing in place sort, and sort returning a sorted array (not modifying the input array).
 I think that the property 'dup' should be a method too, because 'dup' is not a
value of my Array object, it does something.
On the whole I agree: functions which do something obvious shouldn't look like attributes, but it's also interesting to have attributes reading/setting look like attributes reading/writing whether they are implemented by function or not.. renoX
Jan 29 2007
parent reply =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> writes:
renoX Wrote:

 Pierre Reniť Wrote:
 Hello,
 To me, reading a field or a property should not modify the object.
That's debatable, I remember an example of complex Class in a book which memorized the attributes when asked to convert say from x,y to length,angle.
Do you mean that in the object's internal implementation has a cache? To me it's correct. But the behavior of an object (its interface) should not be modified by reading a field. This code : var1 = object.field1 var2 = object.field2 var3 = object.field3 should give the same values to var1, var2 and var3 as this code : var2 = object.field2 var1 = object.field1 var3 = object.field3 Do I have misunderstanded something?
 
 The problem is that just an access to the properties 'reverse' or 'sort' are
modifying my array. These 2 properties should be method instead.
IMHO that's not the real problem, the real problem is looking at the function name, you have no clue whether they do it in place or functional style. What I would prefer is that the name or reverse and sort indicate that they are modifying the array: like in Ruby we would have sort! and sort, sort! doing in place sort, and sort returning a sorted array (not modifying the input array).
 I think that the property 'dup' should be a method too, because 'dup' is not a
value of my Array object, it does something.
On the whole I agree: functions which do something obvious shouldn't look like attributes, but it's also interesting to have attributes reading/setting look like attributes reading/writing whether they are implemented by function or not.. renoX
Bill Baxter Wrote:
 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.
It's a big problem. If a method clear() acts like a property, does it mean that "value = object.clear" will clear my object?
Feb 01 2007
parent reply Daniel Giddings <dgiddings bigworldtech.com> writes:
It's a bit of a tradeoff. Clearing an object like that isn't the 
intended use, but a possible one. It's just bad design, or bad coding. 
Additionally if you want to prevent that happening, set the clear return 
type to void. If you want have a bad API design or code, C++ allows you 
to do so much more ;-)

 From a usability point of view for libraries it allows the API designer 
to hook into property changes to validate assignments, proxy values to 
other objects and the like. All without having to have ugly setXXX, 
getXXX methods for each property. It comes down to how you use the 
language feature; if I was designing a library I would use the property 
syntax to validate the data, store it differently internally, etc, but I 
wouldn't have them do something other than "set or get the property" in 
a general sense. It's similar to overloading the arithmetic operators, 
it's really bad to do if they are overloaded to completely different 
semantics than expected.



Pierre Reniť wrote:
 It's a big problem. If a method clear() acts like a property, does it mean
that "value = object.clear" will clear my object?
Feb 01 2007
parent reply =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> writes:
Daniel Giddings Wrote:

 It's a bit of a tradeoff. Clearing an object like that isn't the 
 intended use, but a possible one. It's just bad design, or bad coding. 
 Additionally if you want to prevent that happening, set the clear return 
 type to void. If you want have a bad API design or code, C++ allows you 
 to do so much more ;-)
No, I want the best possible APIs and the cleanest codes.
 
  From a usability point of view for libraries it allows the API designer 
 to hook into property changes to validate assignments, proxy values to 
 other objects and the like. All without having to have ugly setXXX, 
 getXXX methods for each property. It comes down to how you use the 
 language feature; if I was designing a library I would use the property 
 syntax to validate the data, store it differently internally, etc, but I 
 wouldn't have them do something other than "set or get the property" in 
 a general sense. It's similar to overloading the arithmetic operators, 
 it's really bad to do if they are overloaded to completely different 
 semantics than expected.
Yes, properties should not do other things than "set or get the property". The properties "dup", "sort" and "reverse" do other things. They should not be properties. Bill Baxter Wrote:
 *All* functions and methods in D that take zero or 1 arguments act like
properties.
Does it mean that if I create a method clean() that returns something, it acts like a property? I don't want to make bad code. If I want to create a method that returns somthing without argument, how can I do? Will this method act like a property?
Feb 01 2007
parent reply Daniel Giddings <dgiddings bigworldtech.com> writes:
Pierre Reniť wrote:
 Daniel Giddings Wrote:
 
 It's a bit of a tradeoff. Clearing an object like that isn't the 
 intended use, but a possible one. It's just bad design, or bad coding. 
 Additionally if you want to prevent that happening, set the clear return 
 type to void. If you want have a bad API design or code, C++ allows you 
 to do so much more ;-)
No, I want the best possible APIs and the cleanest codes.
Yes, that can be done through good design. I think the underlying question is should the compiler enforce properties be used as such, which would require another keyword for the property functions.
  From a usability point of view for libraries it allows the API designer 
 to hook into property changes to validate assignments, proxy values to 
 other objects and the like. All without having to have ugly setXXX, 
 getXXX methods for each property. It comes down to how you use the 
 language feature; if I was designing a library I would use the property 
 syntax to validate the data, store it differently internally, etc, but I 
 wouldn't have them do something other than "set or get the property" in 
 a general sense. It's similar to overloading the arithmetic operators, 
 it's really bad to do if they are overloaded to completely different 
 semantics than expected.
Yes, properties should not do other things than "set or get the property". The properties "dup", "sort" and "reverse" do other things. They should not be properties.
They are not properties, they are methods. The D syntax for properties allows you to leave off the () when calling the methods, which is bad programming style as they aren't intended as properties. The only way the compiler could enforce this is to add another keyword for methods you desire as properties, which I think is unnecessary. ie myClass.myMethod is the same as myClass.myMethod() and myClass.myMethod = 5 is the same as myClass.myMethod( 5 ) The alternative is to remove the property syntax shortcuts entirely and go back to setXXX and getXXX which are icky! and lead to unnecessarily verbose API's.
 Bill Baxter Wrote:
 *All* functions and methods in D that take zero or 1 arguments act like
properties.
Does it mean that if I create a method clean() that returns something, it acts like a property? I don't want to make bad code. If I want to create a method that returns somthing without argument, how can I do? Will this method act like a property?
if you make a method clean, it can act like a "property" even if it doesn't return anything as it is a syntax "shortcut" if you like: import std.stdio; class C { void clean() { writefln( "C.clean" ); } } void main() { C c = new C; c.clean; // works, but is bad programming style // c.clean() has a clearer meaning } this doesn't mean you should remove this feature (or any other) because bad programming style or design obfuscates the meaning of the code.
Feb 01 2007
parent reply =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> writes:
Daniel Giddings Wrote:
 if you make a method clean, it can act like a "property" even if it 
 doesn't return anything as it is a syntax "shortcut" if you like:
 
 import std.stdio;
 
 class C
 {
      void clean()
      {
          writefln( "C.clean" );
      }
 }
 
 void main()
 {
      C c = new C;
      c.clean; // works, but is bad programming style
               // c.clean() has a clearer meaning
 }
 
 this doesn't mean you should remove this feature (or any other) because 
 bad programming style or design obfuscates the meaning of the code.
Why not to add a keyword "prop" ? Like in this code : class C { void clean()//This is a method { writefln( "C.clean" ); } prop int somevalue()//This is a property { return 1; } } void main() { C c = new C; c.clean; // won't work because there is no keyword "prop" (=> compile error) c.clean(); //correct int i = c.somevalue; // correct because this is a property } I want this because I want the compiler to prevent me from making mistakes.
Feb 02 2007
parent doob <doobnet gmail.com> writes:
Pierre Reniť Wrote:

 Daniel Giddings Wrote:
 if you make a method clean, it can act like a "property" even if it 
 doesn't return anything as it is a syntax "shortcut" if you like:
 
 import std.stdio;
 
 class C
 {
      void clean()
      {
          writefln( "C.clean" );
      }
 }
 
 void main()
 {
      C c = new C;
      c.clean; // works, but is bad programming style
               // c.clean() has a clearer meaning
 }
 
 this doesn't mean you should remove this feature (or any other) because 
 bad programming style or design obfuscates the meaning of the code.
Why not to add a keyword "prop" ? Like in this code : class C { void clean()//This is a method { writefln( "C.clean" ); } prop int somevalue()//This is a property { return 1; } } void main() { C c = new C; c.clean; // won't work because there is no keyword "prop" (=> compile error) c.clean(); //correct int i = c.somevalue; // correct because this is a property } I want this because I want the compiler to prevent me from making mistakes.
I think it would be good to add a "property" keyword and maybe also "get" and "set". I think also would be nice to add a feature from ruby that i think works something like this: Ruby code: class C { attr_reader :variable1, :variable2, :variable3 } and this will create a private variable and a read property. And ther is also "attr_writer" to create a write property. In D this could look something like this D code: class C { property { int variable1; char[] variable2; int variable3; } } This would create a private variable and a get and set property method. Then you could also write like this: D code: class C { private property { int variable1; char[] variable2; int variable3; } } to make the get and set property methods private. You could write like this: D code: class C { get { int variable1; char[] variable2; int variable3; } } to only make a private variable and a get property method. The get and set methods would be public as default and the variable would always be private. I think it would be great if you could write as i have described above because when you want a private variable and get and set methods that only sets or returns the value. If you would like to do something in the methods it could look like this: D code: class C { private int variable_; public get int variable () { return variable_; } public set int variable (int variable) { if (variable > 3) return variable_ = variable; } }
Feb 03 2007