December 12, 2011
On 12/12/11 9:09 AM, torhu wrote:
> On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>> On 12/12/11 6:24 AM, torhu wrote:
>>> save being a property is a stupid inconsistency.
>>
>> I'm not so sure.
>>
>> Andrei
>
> Why? As far as I can tell, it's inconsistent with what properties are
> used like in other programming languages.

Why?

> Saving something is an action,
> which to me is a different concept.

So if we called .save .state or .current things would be any different?

> If it was called currentState
> instead, that's what I'd call a property.

Ah. So now we're wasting time not on @property (as I'd predicted), but instead on what _names_ are suitable to work with it. I rest my case.

> Making something a property gives it certain connotations that break
> when it's called 'save'. That you can save the state of the range is a
> property, if you will. But the action of doing so is not a property.
> People are going to be surprised when save() doesn't compile. Isn't
> there something called the principle of least surprise?

I think we should only worry about surprising the uninitiated with how poorly designed the whole @property thing is.


Andrei
December 12, 2011
On Monday, 12 December 2011 at 15:07:16 UTC, Jakob Ovrum wrote:
> The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse.

If we start removing features because someone can use them
when deliberately obfuscating their code, we might as well
just abandon the whole idea of programming languages.
December 12, 2011
On 12/12/11 9:07 AM, Jakob Ovrum wrote:
> The old situation where you could
> write complete nonsense code like `std.file.read = "foo.txt";` is far
> worse.

We could have defined a system much better than both.

Andrei
December 12, 2011
On Monday, 12 December 2011 at 15:16:56 UTC, Adam D. Ruppe wrote:
> On Monday, 12 December 2011 at 15:07:16 UTC, Jakob Ovrum wrote:
>> The old situation where you could write complete nonsense code like `std.file.read = "foo.txt";` is far worse.
>
> If we start removing features because someone can use them
> when deliberately obfuscating their code, we might as well
> just abandon the whole idea of programming languages.

Firstly, no feature is removed, it is changed, unless you consider calling completely property-unrelated functions with this syntax a feature. Secondly, it is an extreme example, more commonly occurring examples would be conflating property access with calling a member function with non-trivial complexity. With enforced @property, the compiler helps the user write the most readable code for himself and more importantly, others.
December 12, 2011
On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>> If the programmer sees just "r.save", he
>> doesn't know whether it's a field or a property, and he shouldn't need
>> to know, it should be fast and cheap, and return a consistent value. As
>> far as I know, this isn't always true for save
>
> Why? Save does behave like a field for the vast majority of structs.
>
> Andrei

But save is an abstract interface function, its signature should reflect all possible implementations.
December 12, 2011
On Monday, 12 December 2011 at 15:21:31 UTC, Andrei Alexandrescu wrote:
> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>> The old situation where you could
>> write complete nonsense code like `std.file.read = "foo.txt";` is far
>> worse.
>
> We could have defined a system much better than both.
>
> Andrei

I definitely agree. I think the current situation sucks.

But I also think the previous situation sucks much, much more.

(Unrelated side-note: I am using the web interface and I'm not well seasoned with using newsgroups, is there a better way to reply to multiple small posts than replying to each individually like I just did? I apologize if I'm being spammy.)
December 12, 2011
On 12/12/2011 04:29 PM, Jakob Ovrum wrote:
> On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
>> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>>> If the programmer sees just "r.save", he
>>> doesn't know whether it's a field or a property, and he shouldn't need
>>> to know, it should be fast and cheap, and return a consistent value. As
>>> far as I know, this isn't always true for save
>>
>> Why? Save does behave like a field for the vast majority of structs.
>>
>> Andrei
>
> But save is an abstract interface function, its signature should reflect
> all possible implementations.

Under the premise that a function should be a property iff it behaves like a field, that is impossible.
December 12, 2011
On Monday, 12 December 2011 at 15:29:26 UTC, Jakob Ovrum wrote:
> On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
>> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>>> If the programmer sees just "r.save", he
>>> doesn't know whether it's a field or a property, and he shouldn't need
>>> to know, it should be fast and cheap, and return a consistent value. As
>>> far as I know, this isn't always true for save
>>
>> Why? Save does behave like a field for the vast majority of structs.
>>
>> Andrei
>
> But save is an abstract interface function, its signature should reflect all possible implementations.

Adding on this: I have no problem with save being a property if it's meant/designed to be cheap etc. like with most struct ranges and slices.

I also don't think the name is a problem; if you want to be really pedantic, "save" is actually a noun as well :P
December 12, 2011
On 12.12.2011 16:16, Andrei Alexandrescu wrote:
> On 12/12/11 9:09 AM, torhu wrote:
>>  On 12.12.2011 15:43, Andrei Alexandrescu wrote:
>>>  On 12/12/11 6:24 AM, torhu wrote:
>>>>  save being a property is a stupid inconsistency.
>>>
>>>  I'm not so sure.
>>>
>>>  Andrei
>>
>>  Why? As far as I can tell, it's inconsistent with what properties are
>>  used like in other programming languages.
>
> Why?
>
>>  Saving something is an action,
>>  which to me is a different concept.
>
> So if we called .save .state or .current things would be any different?
>

Yes, completely.  The whole property concept is basically a naming convention.  Except that parentheses are now involved.

x = obj.foo(); // do the foo thing, then return something
x = obj.bar;   // get bar
obj.bar = 42;  // set bar

x = obj.save;  // get save... hm, that doesn't sound right


>>  If it was called currentState
>>  instead, that's what I'd call a property.
>
> Ah. So now we're wasting time not on @property (as I'd predicted), but
> instead on what _names_ are suitable to work with it. I rest my case.
>
>>  Making something a property gives it certain connotations that break
>>  when it's called 'save'. That you can save the state of the range is a
>>  property, if you will. But the action of doing so is not a property.
>>  People are going to be surprised when save() doesn't compile. Isn't
>>  there something called the principle of least surprise?
>
> I think we should only worry about surprising the uninitiated with how
> poorly designed the whole @property thing is.

I'm not trying to defend @property, I think it adds about as much pain as it does gain.  But it's there, and your ranges are using it :)
December 12, 2011
On 12/12/11 9:29 AM, Jakob Ovrum wrote:
> On Monday, 12 December 2011 at 15:14:02 UTC, Andrei Alexandrescu wrote:
>> On 12/12/11 9:07 AM, Jakob Ovrum wrote:
>>> If the programmer sees just "r.save", he
>>> doesn't know whether it's a field or a property, and he shouldn't need
>>> to know, it should be fast and cheap, and return a consistent value. As
>>> far as I know, this isn't always true for save
>>
>> Why? Save does behave like a field for the vast majority of structs.
>>
>> Andrei
>
> But save is an abstract interface function, its signature should reflect
> all possible implementations.

Same goes for many properties.

Andrei