Possible @property compromise

[Michel Fortin]

On 2013-01-31 15:57:12 +0000, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> [...]
> 
> Turns out, this translates to:
> 
> ts.seconds(5);
> 
> and because you can call static methods from an instance (another thing 
> I  don't really like), it made the constructor act like a property!  A  
> completely unintended consequence.
> 
> The only viable solution (this was D1), was to rename the functions so  
> they couldn't be mistaken as properties.  So they all became 
> "fromSeconds"  e.g.  Yuck!

Could also have used global functions instead of static ones inside of 
the class. I still see your point.


> At this point, I think it would be a huge step backwards not to solve 
> (or  at least have a yet-to-be implemented solution for) the above 
> problem.  I  can live with getters simply being parentheses-less 
> functions, that isn't  so bad (though as an API designer, I'd like to 
> have full control over  that).  But using any function as a setter is 
> crap, and will forever be a  wart on D unless we fix it.  It will 
> result in bizarre things like mystery  setters that don't exist, 
> especially with UFCS.

True.

Still, Walter has shown no sign he's willing to accept any solution 
that won't work with most of current code. Just look at his syntax 
proposal in the thread "take it behind the woodshed and shoot it?" if 
you're not convinced. At the same time he has gone to great lengths to 
keep things backward compatible even with experimental syntaxes (I'm 
thinking of user defined attributes). I seriously doubt changing the 
syntax for setters will happen… unless you can make it backward 
compatible.

As for keeping the syntax backward compatible, you could for instance 
propose an attribute to prevent people from using the setter syntax 
when calling a particular function:

	@explicit TimeDuration seconds(float);


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/