View mode: basic / threaded / horizontal-split · Log in · Help
December 12, 2011
Re: Fixing const arrays
On Monday, 12 December 2011 at 16:09:03 UTC, Andrei Alexandrescu 
wrote:
> 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

This is true, and many functions marked @property arguably 
shouldn't be. I think it's a little like the reason 
std.container.SList doesn't have a `length` property: the O(n) 
complexity doesn't match the interface `length` exposes (although 
formalised only in documentation/convention, not code).

If the standard library is allowed to assume `r.save` is a cheap 
operation, in the same fashion it's allowed to assume this(this) 
is cheap, then by all means, it makes sense as a property. The 
only remaining arguments against it are purely about the name, 
and I actually don't think that's relevant.

And just like you can still make a computationally expensive 
this(this) when absolutely necessary, you can do the same with 
save. If most reasonable uses of save have trivial performance, 
it might as well be a property.

I'm still a beginner with ranges, but by my understanding and by 
what some people made it sound like, reasonable uses of save 
include some which are non-trivial. If this is true, then 
removing @property from save encourages people to think more 
about what using it might mean for the code they are writing, 
which is definitely important.
December 12, 2011
Re: Fixing const arrays
On 12/12/11 3:16 PM, 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?

My understanding is the properties are essentially meant to be 
indistinguishable from fields (hence the syntax). save() doesn't really 
act like a field.

Honestly though, I don't like properties at all (in any language). 
Function calls should not be hidden in syntax. IMO if your code contains 
so many get/set functions that properties save you time then you have 
bigger issues.
December 12, 2011
Re: Fixing const arrays
On Monday, December 12, 2011 09:16:53 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?
> 
> > 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.

A property is essentially an abstraction to treat a function like a member 
variable. As such, the naming conventions for a property should be equivalent 
to those for a variable - and that generally means nouns. save is not a noun. 
It's an action verb. So, yes, I think that it's a completely inappropriate 
name for a property. Something ilke state or current _would_ be appropriate 
names. However, at this point, I really don't think that it's worth arguing 
about.

If I were to change it, I'd probably just make save a function rather than 
renaming it, but if we did it, then there would be quite a bit of code that 
would have to be changed essentially over an argument over whether save is 
valid property name because it's not a noun. And while I _don't_ think that 
it's a valid property name, that's getting a bit petty given how much code 
would break.

I'm all for fixing names for camelcasing, because that really affects the 
consistency of the library and is almost always completely objective, but this 
is essentially an argument over the best name for a function, and that never 
has a clear answer. Yes, it's an issue of consistency on some level with 
regards to how we treat and name properties, but that's subjective enough that 
I don't expect us to ever be completely consistent on that.

- Jonathan M Davis
December 12, 2011
Re: Fixing const arrays
On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
> Insisting on the current property semantics was a sizeable mistake of
> this community, and I am sorry we gave into it.

Aside from the fact that the behavior of -property isn't the default, what's 
the problem with @property?

- Jonathan M Davis
December 12, 2011
Re: Fixing const arrays
On Monday, December 12, 2011 17:24:38 Jakob Ovrum wrote:
> I'm still a beginner with ranges, but by my understanding and by
> what some people made it sound like, reasonable uses of save
> include some which are non-trivial. If this is true, then
> removing @property from save encourages people to think more
> about what using it might mean for the code they are writing,
> which is definitely important.

Both save and postblit are supposed to be trivial. Algorithms generally assume 
that copying a range is O(1). There's nothing stopping save and postblit from 
costing more than that, but it's going to harm performance.

- Jonathan M Davis
December 13, 2011
Re: Fixing const arrays
On 12/12/11 1:12 PM, Jonathan M Davis wrote:
> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>> Insisting on the current property semantics was a sizeable mistake of
>> this community, and I am sorry we gave into it.
>
> Aside from the fact that the behavior of -property isn't the default, what's
> the problem with @property?

Other than it being completely useless, requiring more rote 
memorization, and fomenting time-wasting discussion? None.

Andrei
December 13, 2011
Re: Fixing const arrays
On Mon, 12 Dec 2011 19:00:35 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> On 12/12/11 1:12 PM, Jonathan M Davis wrote:
>> On Monday, December 12, 2011 08:46:18 Andrei Alexandrescu wrote:
>>> Insisting on the current property semantics was a sizeable mistake of
>>> this community, and I am sorry we gave into it.
>>
>> Aside from the fact that the behavior of -property isn't the default,  
>> what's
>> the problem with @property?
>
> Other than it being completely useless, requiring more rote  
> memorization, and fomenting time-wasting discussion? None.

Wait, are we talking about @property or .save?

-Steve
December 13, 2011
Re: Fixing const arrays
On 12.12.2011 20:03, Jonathan M Davis wrote:
> On Monday, December 12, 2011 09:16:53 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?
>>
>>  >  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.
>
> A property is essentially an abstraction to treat a function like a member
> variable. As such, the naming conventions for a property should be equivalent
> to those for a variable - and that generally means nouns. save is not a noun.
> It's an action verb. So, yes, I think that it's a completely inappropriate
> name for a property. Something ilke state or current _would_ be appropriate
> names. However, at this point, I really don't think that it's worth arguing
> about.
>
> If I were to change it, I'd probably just make save a function rather than
> renaming it, but if we did it, then there would be quite a bit of code that
> would have to be changed essentially over an argument over whether save is
> valid property name because it's not a noun. And while I _don't_ think that
> it's a valid property name, that's getting a bit petty given how much code
> would break.

It's actually not 'save' being a noun that's the problem.  I just 
thought of a counter-example:

---
struct Foo {
    // the data
    Bar data[];

    // save data on shutdown?
    @property bool save() { return save_; }
    @property bool save(bool shouldShave) { return save_ = shouldSave; }

private:
    bool save_;
}
---
Not meant to be a realistic example, but save is fine as a property here.
December 13, 2011
Re: Fixing const arrays
On Tuesday, December 13, 2011 02:28:29 torhu wrote:
> It's actually not 'save' being a noun that's the problem. I just
> thought of a counter-example:
> 
> ---
> struct Foo {
> // the data
> Bar data[];
> 
> // save data on shutdown?
> @property bool save() { return save_; }
> @property bool save(bool shouldShave) { return save_ = shouldSave; }
> 
> private:
> bool save_;
> }
> ---
> Not meant to be a realistic example, but save is fine as a property here.

You can pretty much always come up with another function with a completely 
different purpose wit the same name.

Personally, the _only_ issue that I have with save is the fact that it's a 
property. The name save works well enough, and I can't think of anything 
that's better.

- Jonathan M Davis
December 13, 2011
Re: Fixing const arrays
On 13.12.2011 02:39, Jonathan M Davis wrote:
> On Tuesday, December 13, 2011 02:28:29 torhu wrote:
>> It's actually not 'save' being a noun that's the problem. I just
>> thought of a counter-example:
>>
>> --- struct Foo { // the data Bar data[];
>>
>> // save data on shutdown? @property bool save() { return save_; }
>> @property bool save(bool shouldShave) { return save_ = shouldSave;
>> }
>>
>> private: bool save_; } --- Not meant to be a realistic example, but
>> save is fine as a property here.
>
> You can pretty much always come up with another function with a
> completely different purpose wit the same name.
>
> Personally, the _only_ issue that I have with save is the fact that
> it's a property. The name save works well enough, and I can't think
> of anything that's better.

Yes, that's my opinion too.
4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home