• renoX <renosky free.fr> Jan 29 2007
• =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> Feb 01 2007
• Daniel Giddings <dgiddings bigworldtech.com> Feb 01 2007
• =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> Feb 01 2007
• Daniel Giddings <dgiddings bigworldtech.com> Feb 01 2007
• =?ISO-8859-1?Q?Pierre_Reni=e9?= <archlinuxien gmail.com> Feb 02 2007
• doob <doobnet gmail.com> Feb 03 2007

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

=?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.

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?

=?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?

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.

=?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.

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