Fixing const arrays

[torhu]

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.