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.

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.

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

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.

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

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.

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

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