On 01/28/2013 06:22 AM, Steven Schveighoffer wrote:
> ...
>
> I would be satisfied with Kenji's implementation.  As I understand it:
>
> @property on a getter would mean implicit calling of the function.
> @property on a setter would mean calling x = y as x(y).
> @property functions could not be called like normal functions.
> Parentheses are optional on normal no-arg functions when used as getters.
> Normal single arg or variadic functions are NOT ALLOWED to be used as
> setters.
> ...

This proposal unfortunately does not work too well because of UFCS.

On Monday, 28 January 2013 at 13:34:33 UTC, Dicebot wrote:
> And if I'll spend few days debugging the case that comes down to my colleague has designed a property that does not behave like a field - I'll go and politely ask to stop doing this.

Do you consider a dynamic arrays' length property to be a good, properly designed property:

array.length = 7;

It does behave like a field, but it's got pretty serious side effects that you just need to know about. And, I don't see much point in having properties that are not allowed to have any side-effects.

On Monday, 28 January 2013 at 16:45:57 UTC, TommiT wrote:
> Do you consider a dynamic arrays' length property to be a good, properly designed property:

No.

> And, I don't see much point in having properties that are not allowed to have any side-effects.

Then you need something other than properties.

On 1/28/13 11:50 AM, Dicebot wrote:
> On Monday, 28 January 2013 at 16:45:57 UTC, TommiT wrote:
>> Do you consider a dynamic arrays' length property to be a good,
>> properly designed property:
>
> No.
>
>> And, I don't see much point in having properties that are not allowed
>> to have any side-effects.
>
> Then you need something other than properties.

Wait, so you're against any writable properties? Maybe there's a confusion somewhere.

Andrei

On Mon, 28 Jan 2013 11:31:33 -0500, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 01/28/2013 06:22 AM, Steven Schveighoffer wrote:
>> ...
>>
>> I would be satisfied with Kenji's implementation.  As I understand it:
>>
>> @property on a getter would mean implicit calling of the function.
>> @property on a setter would mean calling x = y as x(y).
>> @property functions could not be called like normal functions.
>> Parentheses are optional on normal no-arg functions when used as getters.
>> Normal single arg or variadic functions are NOT ALLOWED to be used as
>> setters.
>> ...
>
> This proposal unfortunately does not work too well because of UFCS.

As many have stated in the past, UFCS getter properties can annotate their "this" argument:

@property void by5(this int x) { return x * 5;}

by5 = 1; // error

Another possibility is to only define @property for setters.  This is something I've come to realize that if we are simply going to allow omittable parens on getters, there is no functional value to @property on them except for the rare case of a delegate property.  That was always one of those things where I think too much emphasis was on that as a reason for @property existence, it's very rare.

-Steve

On Monday, 28 January 2013 at 16:59:40 UTC, Andrei Alexandrescu wrote:
>
> Wait, so you're against any writable properties? Maybe there's a confusion somewhere.
>
> Andrei

Ah, yes, there is a confusion between "side-effect" from the pure function point of view and "side-effect" from property functionality point of view. I'd say that property setter should be a pure function with one exception : it is allowed to changed "this" fields. No global state changes, no calls to impure global functions, not even calls to "this" non-property functions.

On Monday, 28 January 2013 at 16:50:27 UTC, Dicebot wrote:
>> And, I don't see much point in having properties that are not allowed to have any side-effects.
>
> Then you need something other than properties.

I think you're putting too much faith on the power of convention and on the similarity between your's and everybody else's notions of how much side effects a settable property can have while not giving the user any surprises.

Let's say your type has three properties:
#1: start_time
#2: end_time
#3: duration

Changing any one of those properties must (logically) change at least one other property. Therefore, you can't just pretend that properties are simple data fields.

On Monday, 28 January 2013 at 17:14:31 UTC, TommiT wrote:
> On Monday, 28 January 2013 at 16:50:27 UTC, Dicebot wrote:
>>> And, I don't see much point in having properties that are not allowed to have any side-effects.
>>
>> Then you need something other than properties.
>
> I think you're putting too much faith on the power of convention and on the similarity between your's and everybody else's notions of how much side effects a settable property can have while not giving the user any surprises.
>
> Let's say your type has three properties:
> #1: start_time
> #2: end_time
> #3: duration
>
> Changing any one of those properties must (logically) change at least one other property. Therefore, you can't just pretend that properties are simple data fields.

That is no different from volatile variables. My notion is at least same as C# guideline authors, so it should be not that rare. It all comes from "property == variable" mantra.

On Monday, 28 January 2013 at 17:30:40 UTC, Dicebot wrote:
>> Let's say your type has three properties:
>> #1: start_time
>> #2: end_time
>> #3: duration
>>
>> Changing any one of those properties must (logically) change at least one other property. Therefore, you can't just pretend that properties are simple data fields.
>
> That is no different from volatile variables.

If you think my example of {start_time, end_time, duration} represents proper use of properties, then I don't see why you oppose array.length. To me it seems like the same thing. Array has some length, and you can change it by changing its length property. T represents a certain time range, and you can change it by changing any of its three properties {start_time, end_time, duration} which describe that time range.

> My notion is at least same as C# guideline authors, so it should be not that rare. It all comes from "property == variable" mantra.

I'm just saying that when you read some code written by some person X, you can't rely on person X having the same notion of what properties should be as you do. For this reason you can't only read the documentation of methods and skip reading the documentation of properties, because properties may do/change things that you wouldn't have made them do/change.

On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
> If you think my example of {start_time, end_time, duration} represents proper use of properties, then I don't see why you oppose array.length. To me it seems like the same thing. Array has some length, and you can change it by changing its length property. T represents a certain time range, and you can change it by changing any of its three properties {start_time, end_time, duration} which describe that time range.

T changes its inner encapsulated states. Period. It is no different that properties that calculate result on the fly, like range.empty (which is good property usage).

Array.length allocates. Takes from some global resources, takes some considerable time, calls some global allocating function.

For me it is a crucial difference that pushes symbol to the world of functions.