December 12, 2011 Re: Fixing const arrays | ||||
---|---|---|---|---|
| ||||
Posted in reply to torhu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakob Ovrum | 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
|
Copyright © 1999-2021 by the D Language Foundation