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