Properties

[Nick Sabalausky]

"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.

> set has a parameter, and
> the programmer should be able to name it.
>
> Also, removing the parentheses would be confusing. I believe it might be
> better to make them look like this, even:
>
> property int length {
>    auto get() { .. }
>    void set(auto name) { .. }
> }
>
> So they would clearly be function declarations.
>

What benefit would that provide?

Downside:
The fact that they're part of the language-defined property getter/setter 
syntax renders any explicitly-stated parameter and return-value information 
completely redundant. Of course, I'm aware that sometimes redundancy can be 
good since it can help catch errors, but this particular redundancy doesn't 
do anything to help catch errors. In fact, it could cause confusion because 
it obscures the fact that "get" and "set" are special function names within 
a "property" block. (Plus it's just not as clean-looking as a C#-style "get 
{} set{}")

I suppose explicitly stating the return type and parameter lists could open 
the door for "multitype" properties that could "get" or "set" different 
types without relying on the caller to cast/convert. I'm not sure how I feel 
about that though...it might be nice...

>> 2. You shouldn't have to manually define a private var to go along with
>> the property. In languages with real properties, the following idiom is
>> used constantly:
>>
>> private int _var;
>> public property int var {
>>    get { return _var; }
>>    set { _var = $; }
>>    void opIncrement() { _var++; }
>> }
>>
>> Why should that be needed? It should be like this:
>>
>> public property int var {
>>    // int internalValue; // Automatically created (but named better)
>>    get { return internalValue; }
>>    set { internalValue = $; }
>>    void opIncrement() { internalValue++; }
>> }
>>
>> In the minority of cases where a property doesn't need this variable,
>> "internalValue" can just be optimized away.
>
> If you really want that behavior, you should just use a public variable.
> Even changing it to a real property later would not matter for the public
> interface.
>

The bodies of those get's and set's were just trivial examples. I agree an 
actual property like that would be pointless. But a typical use-case for 
properties is to intercept accesses to a member variable and perform some 
sort of action on each access (validation, logging, updating a related 
value, etc). In other words, you still frequently need the "private int _x; 
property int x {}" idiom. In my experience, these sorts of things are the 
most common uses for properties, and even if they weren't it would be simple 
enough to optimize away the implied private var whenever it's not needed, so 
the feature would never cause any trouble, it would just help in many cases 
(plus provide a standardized name).