On 1/28/13 4:32 PM, Dicebot wrote:
> On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu wrote:
>> I guess you hate if people want their bigints to assign with a = b.
>
> Have never used bigints. You mean that copy construction upon assignment
> allocates too? Yes, I do now like this, too, but see no sane to get
> around this as it will feel unnatural either way.

So maybe it's time to adjust your preferences.

> Arrays, however, will
> not suffer at all from switching to array.resize(42) syntax from
> array.length = 42 syntax.

Well I think this is a given now. So again - time to adjust preferences :o).


Andrei

On Monday, 28 January 2013 at 21:03:04 UTC, Max Samukha wrote:
> Let's face it: there are *no* objective criteria for determining whether a mutator should be a function or property setter.

Yes, but also it's should be a lightweight action (main idea).

As proposal:

http://forum.dlang.org/post/ydcjggoibjmuuoobgrvq@forum.dlang.org

And C# Property notes
http://msdn.microsoft.com/en-us/library/w86s7x04.aspx
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

and quote

> At all, it looks like C# style in D Way.
> --no-parenthesis for current behaviour for non-property functions.

On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu wrote:
> On 1/28/13 4:32 PM, Dicebot wrote:
>> On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu wrote:
>> Arrays, however, will
>> not suffer at all from switching to array.resize(42) syntax from
>> array.length = 42 syntax.
>
> Well I think this is a given now. So again - time to adjust preferences :o).

My feeling is that the array.length getter/setter problem is affected by the perceived assymetry between the getter and the setter operation.

Even more, that feeling is exacerbated by the involvment of a canonical type. People expect some expensive background operations for user-defined, complicated types, but not for canonical types. Properties too, are plagued by this, but at least there the choice is explicitly marked and assumed.

As for the a=b bigInts vs the array.length=5 problem: the former operation affects the content of a and b. The latter not only affects the content of array.length, but also the very content of array itself. I know the border is thin, however, it exists at the psychological level, since many will gladly accept reallocation in a=b, but not in array.length=5.

Maybe is just the power of habit. Maybe not.

On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu wrote:
> So maybe it's time to adjust your preferences.

Ye, I know, I speak too much :( Sure, switching to low profile mode.

On Tuesday, 29 January 2013 at 10:26:54 UTC, Dicebot wrote:
> On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu wrote:
>> So maybe it's time to adjust your preferences.
>
> Ye, I know, I speak too much :( Sure, switching to low profile mode.

Reason and reasonable trade-off should prevail.

On Monday, 28 January 2013 at 21:54:21 UTC, Michael wrote:
> On Monday, 28 January 2013 at 21:03:04 UTC, Max Samukha wrote:
>> Let's face it: there are *no* objective criteria for determining whether a mutator should be a function or property setter.
>
> Yes, but also it's should be a lightweight action (main idea).

I think we need something more measurable than lightweight-ness to justify a language feature.

>
> As proposal:
>
> http://forum.dlang.org/post/ydcjggoibjmuuoobgrvq@forum.dlang.org
>
> And C# Property notes
> http://msdn.microsoft.com/en-us/library/w86s7x04.aspx
> http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
>
> and quote
>
>> At all, it looks like C# style in D Way.
>> --no-parenthesis for current behaviour for non-property functions.

I agree with Adam's view and I really think @property is a good thing.

APIs have to specify their semantics and clearly distinguish properties from functions, which may be implemented similarly but *mean* different things. Basically a property is a *thing* or a characteristic, normally a noun, whereas a property is an action, normally a verb.

As a special case, a property can be a delegate or function, and calling it with () would apply the parens to the delegate (which the user is explicitly calling), but not to the property.

Properties as they are can also be used to emulate "indexed properties", as in other languages. If a property's type is a struct that implements [] and []= then we can do:

image.pixels[x,y] = Rgb(255,0,0);

And yes, I think properties should always be called ["used" I would rather say] without parens, and functions always be called with parens. Isn't it like this in other languages, e.g. C#, BTW?

But anyway as I don't develop the compiler, I speak from a distance, and I'm not aware of the implementation complications there may be...



On Thursday, 24 January 2013 at 13:43:34 UTC, Adam D. Ruppe wrote:
> No, god no. This would break code AGAIN and still not fix the problems, instead introducing new ones!
>
> I think any property proposal that talks about parenthesis in the definition is wrong. With a good definition, the existing type system will handle the parenthesis.
>
> @property int foo() { return 10; }
>
> foo(); // the correct error is "type int is not callable"
>
> This is the key point:
>
> A property is NOT a function as far as user code is concerned. That's just an implementation detail.
>
> As far as user code is concerned, a property IS its return value.
>
>
> If you implement that, leaving all the other rules in the language exactly the same, we'll actually fix some problems without breaking the overwhelming bulk of existing code.
>
>
> Fixing the rest of the problems is then about getting op*Assign to work right.
>
>
>
> Functions not marked @property should NOT change AT ALL from what we have now. I am against removing the existing optional parenthesis rule, and I am against removing the @property decoration.
>
> Fix it this time, don't break it in a different place.

On 1/29/13 5:26 AM, Dicebot wrote:
> On Monday, 28 January 2013 at 21:43:25 UTC, Andrei Alexandrescu wrote:
>> So maybe it's time to adjust your preferences.
>
> Ye, I know, I speak too much :( Sure, switching to low profile mode.

That's not the right conclusion.

Andrei

29-Jan-2013 17:27, Alvaro пишет:
> I agree with Adam's view and I really think @property is a good thing.
>
> APIs have to specify their semantics and clearly distinguish properties
> from functions, which may be implemented similarly but *mean* different
> things. Basically a property is a *thing* or a characteristic, normally
> a noun, whereas a property is an action, normally a verb.
>

A typo pretty much ruined otherwise good point :)


-- 
Dmitry Olshansky

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.

Progressively, I start considering this as a not-so-bad idea.

Anyway, the issue of @property should be cleared up. The current state of affairs is poisoning the language.