Properties

[Nick Sabalausky]

"Chad J" <gamerchad at __spam.is.bad__gmail.com> wrote in message 
news:gk5fch$2ldo$1 at digitalmars.com...
> Michiel Helvensteijn wrote:
>> Nick Sabalausky wrote:
>>
>>> 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.
>>
>
> That's not quite why it was suggested.
>
> I actually like the idea.
>
> It is true that a public member would be preferred in the trivial case.
> In the general case though, people will have some internal value they
> are working with and whenever someone works with it they want side
> effects to happen.
> Here's an example:
>
> int nTimesVarRead = 0;
>
> public property int var
> {
>    get
>    {
>        nTimesVarRead++;
>        return internalValue;
>    }
>
>    set { internalValue = $; }
> }
>
> compare against:
>
> int nTimesVarRead = 0;
> int m_var; // Annoying extra declaration that is common practice.
>
> public property int var
> {
>    get
>    {
>        nTimesVarRead++;
>        return m_var;
>    }
>
>    set { m_var = $; }
> }
>
> Thus I rather like that idea.
>
> Perhaps, since the compiler knows the name of the property, the name of
> the generated internal value could just be the name of the property:
>
> public property int var
> {
>    get { return var; }
>    set { var = $; }
> }
>
> public property int foo
> {
>    get { return foo; }
>    set { foo = $; }
> }
>
> etc.

That I don't like, for the same reason VB's syntax for returning a value 
from a function drives me nuts:

Function Foo
   Foo = 7
End Function

It's a DRY violation. Anytime you change the name of Foo, it's just that 
much more that also needs to be updated. And if you copy it to use as a 
starting point for another function, then again you have that much more to 
update. Granted, that can all be solved with an refactoring feature in the 
editor, but if I wanted my language to be reliant on IDE features, I'd use 
Java.

As long as it's come up, this is another case that frequently annoys me:

template foo(alias a /*...*/)
{
    const char[] foo = /*some fancy code-generation here*/;
    //pragma(msg, "foo: "~foo); // for debugging the template
}
mixin(foo!(/*...*/));

I do that frequently, and when developing them I'm constantly changing 
names, and ever time I do, I have to change the name and then copy-paste the 
new name to at least three other places. PITA.