digitalmars.D - Why to have properties to sort or duplicate arrays ?
- =?ISO-8859-1?Q?Pierre_Reni=e9?= (4/4) Jan 27 2007 Hello,
- Hasan Aljudy (2/7) Jan 27 2007 Well, in D, properties are just normal methods.
- Bill Baxter (7/20) Jan 27 2007 Which allows one to write nifty code like:
- Chris Miller (5/8) Jan 27 2007 Except these are magic properties and can't be called like functions, ev...
- Derek Parnell (19/27) Jan 27 2007 Yes, this is a significant design mistake that has always been with us.
- =?ISO-8859-1?Q?Pierre_Reni=e9?= (2/38) Jan 28 2007 I don't think there is a need to change the property concept. Just depre...
- Bill Baxter (22/23) Jan 28 2007 *All* functions and methods in D that take zero or 1 arguments act like
- Kevin Bealer (16/50) Jan 28 2007 A functional programming language would probably do that but personally
- renoX (7/11) Jan 29 2007 IMHO that's not the real problem, the real problem is looking at the fun...
- =?ISO-8859-1?Q?Pierre_Reni=e9?= (13/38) Feb 01 2007 Do you mean that in the object's internal implementation has a cache? To...
- Daniel Giddings (16/17) Feb 01 2007 It's a bit of a tradeoff. Clearing an object like that isn't the
- =?ISO-8859-1?Q?Pierre_Reni=e9?= (7/24) Feb 01 2007 Yes, properties should not do other things than "set or get the property...
- Daniel Giddings (32/58) Feb 01 2007 Yes, that can be done through good design. I think the underlying
- =?ISO-8859-1?Q?Pierre_Reni=e9?= (22/44) Feb 02 2007 Why not to add a keyword "prop" ?
- doob (59/108) Feb 03 2007 I think it would be good to add a "property" keyword and maybe also "get...
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
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
Bill Baxter <dnewsgroup billbaxter.com> Hasan Aljudy wrote:Pierre Renié wrote: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. --bbHello, 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
On Sat, 27 Jan 2007 19:18:32 -0500, Hasan Aljudy <hasan.aljudy gmail.com> wrote: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.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
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
Derek Parnell Wrote:On Sat, 27 Jan 2007 18:00:10 -0500, 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.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 28 2007
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
Derek Parnell wrote:On Sat, 27 Jan 2007 18:00:10 -0500, Pierre Renié wrote: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[]; KevinHello, 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;
Jan 28 2007
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
renoX Wrote:Pierre Renié Wrote: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?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.Bill Baxter Wrote: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.. renoXPierre 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?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.
Feb 01 2007
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
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
Pierre Renié wrote:Daniel Giddings Wrote: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.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.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.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: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.*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
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
Pierre Renié Wrote:Daniel Giddings Wrote: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; } }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 03 2007