Fixing const arrays
torhu
no at spam.invalid
Mon Dec 12 07:45:17 PST 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 :)
More information about the Digitalmars-d
mailing list