Properties

Nick Sabalausky a at a.a
Thu Jan 8 11:01:28 PST 2009


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





More information about the Digitalmars-d mailing list