[phobos] Time to get ready for the next release

[Robert Jacques]

On Fri, 22 Apr 2011 10:39:02 -0400, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:

> Bug reports.  People having stupid arguments just like this one on why  
> you should change how the code works to fit their style ;)
>
> Essentially, ambiguously named functions in the context of "I can call  
> this as a property or a function" lead to people getting surprising  
> behavior and then complaining about the surprise, when I can do nothing  
> about it.
>
> I've actually had this happen.  I had to change function names in Tango  
> in order to avoid people complaining.  The example was, I had a bunch of  
> generator functions in TimeSpan, like
>
> // create a time spand that represents the given number of seconds
>
> static TimeSpan seconds(int s)
>
>
> which would be used like this:
>
> auto s = TimeSpan.seconds(5);
>
> But it could also be used as a property.  So this compiled and  
> constructed a temporary time span and throw it away:
>
> TimeSpan s;
>
> s.seconds = 5;
>
> So we had to change seconds to fromSeconds.  It still allows code like  
> this:
>
> s.fromSeconds = 5;
>
> but instead of being disallowed, it just looks horrible, hopefully  
> cluing the reader to go examine the documentation for TimeSpan.  That's  
> the best we can do.  I have no power to enforce the usage.

You know, the first thought I had when seeing this code was, "Why didn't  
you capitalize the name of your inner struct/class in the first place?".  
My second thought was, hmm..., I wonder if there would be a way to prevent  
accessing static members from instances? (There's a pretty serious loss of  
functionality bug regarding struct opCall being overloaded by ctors that's  
basically the same thing.) Third, came criticisms of naming a factory  
method 'seconds' in the first place (noun/verb distinctions, etc), and the  
associative criticisms of fixing a bad design via a proverbial  
sledgehammer. Forth, came the realization that in D2 'seconds' would  
probably be pure, which would cause s.seconds = 5 to be compiler error.  
Currently I'm pondering whether capitalized factory methods, in order to  
mimic ctor syntax, would be an acceptable design. I doubt anyone would  
every have tried s.Seconds = 5, and thanks to auto, I also doubt anyone  
would call TimeSpan.Seconds s. And unlike (an impure) s.seconds = 5,  
TimeSpan.Seconds s; simply doesn't compile. Plus, it self-documents the  
factory concept in the name.

Still, this feels like a valid point weakened by a poor (or at least  
debatable) example. You wouldn't have additional examples handy, would  
you? (links to bug reports, would be more than acceptable)