On Mon, Jan 28, 2013 at 07:04:21PM +0100, Dicebot wrote:
> 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.

In the dinosaur age of Motorola 6502 processors, writing certain values to certain "magic" memory addresses triggers side-effects like switching the console into graphics mode. One could argue this is bad design, but it *is* a precedent for side-effects when assigning values to what can be thought of as "just a variable". By comparison, array.length is pretty tame (no visible side-effects except that the array becomes longer).


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On Monday, 28 January 2013 at 18:10:33 UTC, H. S. Teoh wrote:
> By comparison, array.length is
> pretty tame (no visible side-effects except that the array becomes
> longer).

... *and* possibly relocated in memory, so that it no longer aliases any other slices originally pointing to the same chunk of data.

This is the main reason why .length looks far to innocent in my regard - although I don't really feel strongly about the issue.

David

On Monday, 28 January 2013 at 18:04:22 UTC, Dicebot wrote:
> 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.

The question "what is or should be a property?" is a question of semantics. I don't see what performance or those implementation details you mentioned have to do with semantics.

What if our container type wasn't a dynamic array? Let's say it's a pseudo container that pretends to be a vector of consecutive int values, but in reality it just has two integers which denote the beginning and the end of the range. Now changing the length property of that container takes constant time (it just sets the end value anew).

On 1/28/13 1:04 PM, Dicebot wrote:
> 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.

I guess you hate if people want their bigints to assign with a = b.

Andrei

On 2013-01-28 18:11, Dicebot wrote:

> 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.

What about getters and setters and gets and sets a value from a cache?

-- 
/Jacob Carlborg

On 2013-01-28 18:07, Steven Schveighoffer wrote:

> 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.

I think @property adds clarity and shows intent. For example, now that we have UDA's I have create a struct called "attribute" which I use as an attribute for other structs to should be attributes:

struct attribute {}

@attribute struct foo {}

@foo int a;

Here @attribute shows the intent. This is also why I like to have explicit interfaces and abstract classes compared with C++ which doesn't not.

-- 
/Jacob Carlborg

On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu wrote:
> On 1/28/13 1:04 PM, Dicebot wrote:
>> 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.
>
> I guess you hate if people want their bigints to assign with a = b.
>
> Andrei

widget.height = 100 should be condemned, too - it changes the state of the entire GUI system.

Let's face it: there are *no* objective criteria for determining whether a mutator should be a function or property setter.

On Monday, 28 January 2013 at 19:43:39 UTC, Jacob Carlborg wrote:
> On 2013-01-28 18:11, Dicebot wrote:
> What about getters and setters and gets and sets a value from a cache?

Would not have made them properties either. It is somewhat similar to cache and const vs logical const issue. But you are right, this is were personal preferences start varying a lot, I don't realistically hope someone will give me language that restrictive in its core for my needs :) Just expressing personal attitude because I am in the hospital, bored and have a crazy amount of free time to chat on newsgroup :)

That may sound weird but I do like when core language features are very restrictive and require programmer to express his intentions verbosely. And provide _possibility_ to do cool stuff via advanced clearly separated advanced features. Like @safe vs @system but for syntactic language features. Not gonna convince anyone but at least pushing it my way makes me feel good :)

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. Arrays, however, will not suffer at all from switching to array.resize(42) syntax from array.length = 42 syntax.

On Mon, 28 Jan 2013 05:26:43 -0800, Regan Heath <regan@netmail.co.nz> wrote:

> On Sat, 26 Jan 2013 16:29:16 -0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/26/13 8:21 AM, Jacob Carlborg wrote:
>>> On 2013-01-25 22:20, Andrei Alexandrescu wrote:
>>>
>>>> That's right with the amendment that we're looking for a solution, not
>>>> pushing one. Even the title of the thread is a question.
>>>>
>>>> Clearly properties are good to have. In an ideal world we wouldn't need
>>>> a keyword for them and we'd have some simple rules for determining
>>>> property status (especially when it comes to writes). If syntactic help
>>>> is necessary, so be it. We want to make the language better, not worse.
>>>
>>> It's always possible to avoid keywords in favor of syntax. Example:
>>>
>>> Declaring a getter:
>>>
>>> int foo {}
>>>
>>> Just as a regular function declaration but without the parentheses.
>>>
>>> Declaring a setter:
>>>
>>> void foo= (int value) {}
>>>
>>> Append an equal sign to the function name.
>>
>> This is interesting. I wonder how to make it work for UFCS functions (which _do_ have one argument).
>
> Do the c# thing and use 'this'? i.e.
>
> int foo(this Person p) {}
> void foo= (this Person p, int value) {}
>
> R
>

Yes, C# uses a 'this' argument as it's first parameters to make it an Extension Method.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/