Community

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

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