On Fri, 22 Apr 2011 10:39:02 -0400, Steve Schveighoffer
<[email protected]> 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)
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
