Why to have properties to sort or duplicate arrays ?

[Pierre Renié]

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?