"Michiel Helvensteijn" <nom...@please.com> wrote in message news:gk5h9r$2p7...@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.
