On Mon, 24 Feb 2014 15:36:43 -0800, Meta <[email protected]> wrote:
On Monday, 24 February 2014 at 23:07:07 UTC, Adam Wilson wrote:
Well, we keep voting down replacement candidates, which incidentally,
is exactly what happened with the std.signals replacement, so I view
this as an orthogonal issue to whether or not it should be included
after passing a review. I don't think the fact that a module might not
be perfect after review should stop us from approving a module that
offers completely new functionality AND passed a review. Handling the
problems after inclusion is what bugzilla is for.
I guess std.signals was a bad example, as there *was* a proposed
replacement. However, there were real problems with the replacement that
made it not suitable for inclusion. If I recall, these were largely API
issues, which are the hardest to change. If we had've accepted the new
std.signals despite the issues raised, several years down the road it
might turn out to be as broken as the old implementation (no offense to
the author, this is just for the sake of argument), and we are unable to
replace it for fear of breaking code. There are then 2 options: support
the old API with its broken behaviour in the same module as the new API,
or introduce std.signals2 or the like, which people have shown
resistance to in the past. I think that it's very important to be
careful as to what goes into Phobos at this point, as it's going to
become increasingly difficult to change anything.
Ok. Then by that standpoint we have two remaining options. A) Don't ever
change existing code because you might breaking someone else's depending
code on accident. Even without an API change, a change in how a function
does it's processing can result in incorrect behavior in down-stream code.
B) Never introduce new modules because we are terrified that the API might
not be right in five years.
It is unrealistic in the extreme to demand that a new module in Phobos
meet some arbitrary future compatibility bar. We routinely make changes to
Phobos that break people's code in subtle ways that don't produce compiler
errors and we never hear about it because no sane programmer expects a
standard library to be a static thing that will never ever ever change in
any way what so ever so that they can expect the exact same behavior five
years from now. No, they go fix it and move on.
"OMG! We can't add this! It might not be the right API in the future!" By
that reasoning we should halt all work on Phobos ever. After all, we might
break something or a new API might not be perfect in five years after a
new language feature allows an obviously better way of implementing that
API. As reasoning goes, the best word I am come up with to describe it is
"naive". It is a purely fear based response based on some unspecified and
unknown future circumstance. Newsflash, you can't predict the future,
which incidentally, is why API's change!
The reason std.signals replacement got voted down was because it wasn't
API compatible with the original. This is despite the fact that nobody
stood up to say that they use the current implementation and like it.
Anybody who did use it said that they are desperate for a replacement. No
the current std.signals is universally reviled and almost completely
unused but we can't change it because of the mythical silent user who
might be out there coding under a rock with no Internet and isn't voicing
their opinion. Well, guess what, if you don't speak-up you have no right
to blame it on the people who did and decided to changed it. You had your
chance, stop whining and go update your code.
We are programmers. It is our JOB to deal with changes in the API/ABI/ISA.
We don't have the RIGHT to whine about change because dealing with change
is what we DO. If we aren't dealing with change we're working on something
that isn't used at all and therefore pointless. I'm all for pointless
pursuits, but don't hamstring me and my non-pointless pursuits with them.
I wanted std.signals in the new form badly, but now I can't have it, and
Aurora is going to suffer mightily for it. Now I get to go off and make my
own substandard iteration of Signals, because some people whined about how
the API wasn't backwards compatible, even though it's widely acknowledged
that almost nobody uses it and those that do would've been happy to move
to the new signals.
Note, I am not talking about voting down modules that are obviously poorly
implemented, I am talking about modules that work well and can do the task
they purport to do with as few bugs as possible. If the module can do what
it says it can, and the API isn't horrible, then we should default to
adding it. Griping about the API five years from now is just bikeshedding,
write up a pull and get that reviewed, chances are high it'll get rejected
because the changes are worse anyways.
The only difficulty with changing anything is in your head. In practice,
programmers who actually need to get things done expect it.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
