Properties

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:gk5fo7$2m80$1 at digitalmars.com...
> "Michiel Helvensteijn" <nomail at please.com> wrote in message 
> news:gk5b4m$2ekd$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>
>>> 1. Like in C#, you shouldn't need to define paramater lists for "set" 
>>> and
>>> "get". They're always going to be the same. In the case of "set", it's
>>> always going to be just the one param, and it'll be the new value, so 
>>> just
>>> make a special predefined var. Something like:
>>>
>>> get { return this.len; }
>>> set { this.len = value; } // "value" (like in C#), or "$" or something
>>> like that
>>
>> I have to disagree. By that logic, we would abolish parameter-names
>> altogether and access formal parameters by number.
>
> I don't think that follows at all. Function parameters have user-definable 
> names because functions are a general concept that, for all the syntax is 
> aware, could have any number of params that could each represent just 
> about anything. Property getters/setters are different: A property getter 
> is ALWAYS going to take nothing in and return a value of the same type as 
> the property that represents the value of the property. Otherwise it 
> wouldn't be a property getter. A property setter is ALWAYS going to return 
> nothing and take in exactly one argument, of the same type as the 
> property, and that value will ALWAYS represent the intended new value. 
> Otherwise it wouldn't be a property setter. With this information, 
> requiring a custom user-defined name for the setter parameter becomes 
> completely frivolous. You may as well require people to make up their own 
> names for "void", "if", "while" and "{some array here}.length": they're 
> always going to mean the same thing so it's much better to have it 
> standardized.
>

Sorry, Ary beat me to it. And much less verbosely ;)