View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2011
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
Re: Fixing const arrays
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
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home