View mode: basic / threaded / horizontal-split · Log in · Help
January 27, 2007
Why to have properties to sort or duplicate arrays ?
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.
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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.
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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.
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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.
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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;
}
January 28, 2007
Re: Why to have properties to sort or duplicate arrays ?
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
Top | Discussion index | About this forum | D home