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

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?

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?

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?

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.

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.

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