Revised RFC on range design for D2
Michel Fortin
michel.fortin at michelf.com
Tue Sep 30 06:09:51 PDT 2008
On 2008-09-29 23:12:44 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> said:
> Indeed, whether or not something can be used as a property will depend
> on the qualifiers in vigor.
And I think this is why binding the availability of the proprety syntax
of the setter to the existance and visibility of a getter is not a good
idea.
Basically, doing this makes the "()" syntax safer, and the "=" version
more fragile, as the later could become non-functionnal in all kinds of
situations where the getter becomes unavailable (removal, deprecation,
change in protection, change in constness of the parent, etc.). It
means that if I remove or change the visibility of a getter in a
program (because it has been found to be erroneous, dangerous, and/or
badly used), I will have to change all the calls to the corresponding
setter to use the parenthesis form.
This can be a nuisance while refactoring. It also means that I can't
just remove the getter and attempt to recompile to check if it's called
somewhere without inducing compilation errors where the setter is used.
And I'm sure it'll encourage some silly ones who want to write
write-only properties to add a dummy getter that throws an exception,
disregarding static checking. I can already see some people
recommanding always using the parenthesis syntax when calling setters
because then you know you won't have to change it later when you
refactor your code; I know I would consider it if I got biten by this,
after all we're already doing this in other languages and it's not that
painfull.
So I think this idea brings unnecessary coupling between functions,
with more drawbacks than benefits. Don't mistake me, I liked your idea
at first, especially because I'm not fond of adding a new syntax just
for diallowing another, but now I realise don't like its implications
of the implicit coupling of the setter with the getter.
I believe explicit coupling would be better, and that probably means an
explicit property syntax as others have requested. But then again, I
don't mind much if things stay like they are.
- - -
Another funny example:
module a;
void func(int a);
module b;
int func();
module c;
import a;
import b;
void main()
{
func(func); // compiles... so
func = 5; // compiles too!
}
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d-announce
mailing list