Properties

[Nick Sabalausky]

"Michiel Helvensteijn" <nomail at please.com> wrote in message 
news:gk5h9r$2p7g$1 at digitalmars.com...
> Nick Sabalausky wrote:
>
>>> Perhaps the implicit declaration "value" (or whatever *you* would call
>>> it) inadvertently overshadows a member variable with that name. That
>>> could result in a bug that would be pretty hard to find.
>>>
>>
>> Overshadowing is already a potential issue anyway, with or without
>> properties. Even a user-defined name could still accidentally overshadow
>> something.
>
> Sure, but in that case both of the declarations are explicit. Now there's 
> an
> invisible variable blocking a visible one. Could be quite confusing.
>

Possibly. But I've used it a lot in C# and never had a problem. And syntax 
highlighting can help (as well as the fact that C#'s "value" looks much more 
like a keyword than my purely tentative "newValue").

>> Also, using "$" could help minimize overshadowing, the only
>> thing that could ever clash with that is the "array.length" shorthand
>> inside array slices/indexes (and even that already has potential for
>> clashing, specifically when using nested indexes).
>
> Using $ just doesn't make much sense. To what lengths are you willing to 
> go
> to avoid typing a few more characters? Or do you really find $ more
> readable? Who could guess that $ inside the set function stands for its
> invisible parameter?
>

It's not so much about saving typing as the clarity that comes from 
consistency. And as with "array[0..$]", or the "a + b" stuff in phobos2's 
functional-style modules, it's easy if you're aware of it (you can't expect 
every new language feature to be obvious at a glance to someone who's never 
glanced at the docs). I'll grant that "$" may not be as descriptive as, say 
"newValue", but I'd certainly find it much more readable than having it 
named something completely different in every setter in the codebase.