www.digitalmars.com         C & C++   DMDScript  

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

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.

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

 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.

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 ;-)

 
  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.

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 ;-)


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.

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