On 3/13/14, 7:48 AM, Joseph Rushton Wakeling wrote:
On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu wrote:
I hear you. Time to put this in a nice but firm manner: your arguments
were understood but did not convince.
The problem is that this remark could be made in both directions. I
understand some of the motivation for this decision, but the way it's
been announced and rationalized is very problematic.
That naturally leads to questions about whether it's the right decision
or not, and to be honest, I don't think the follow-ups from you and
Walter have adequately addressed those concerns.
At a level it's clear it's not a matter of right or wrong but instead a
judgment call, right? Successful languages go with either default.
Problem 1 -- the announcement as made gives the impression that a known,
planned, desirable breaking change with a well-defined deprecation path
is to be cancelled because of a client's response to an unplanned and
unannounced breakage. You need to make the case for why
well-signposted, well-executed deprecation paths are a problem that sits
on the same level as the kind of unexpected breakage this client
encountered.
The breakage was given as an example. We would have decided the same
without that happening.
Problem 2 -- perhaps there's a broader context that you can't discuss
with us because of commercial confidentiality, but the impression given
is that this decision has been taken substantially in reaction to one
bad client response. This gives the impression of a knee-jerk reaction
made under stress rather than a balanced decision-making process. More
so because it's not clear if the client would have the same problem with
a well-executed deprecation process.
More than sure a well-executed deprecation process helps although it's
not perfect. We're not encumbered by exhausting confidentiality
requirements etc.
Problem 3 -- I don't think this decision has adequately acknowledged the
original rationale for favouring final-by-default. Walter has discussed
the speed concern, but that was not the killer argument -- the one which
swung the day was the fact that final-by-default makes it easier to
avoid making breaking changes in future -- see e.g.:
http://forum.dlang.org/thread/pzysdctqxjadoraee...@forum.dlang.org?page=10#post-mailman.246.1386164839.3242.digitalmars-d:40puremagic.com
http://www.artima.com/intv/nonvirtualP.html
So, if avoiding breaking change in future is a strong goal, allowing the
transition to final-by-default is a clear contribution to that goal.
There's some underlying assumption here that if we "really" understood
the arguments we'd be convinced. Speaking for myself, I can say I
understand the arguments very well. I don't know how to acknowledge them
better than I've already done.
Finally, I'd say that to my mind, these kinds of announcements-by-fiat
that come out of the blue and without warning, while not as bad as
unexpected code breakage, are still pretty bad for the D user
community. We need to be able to have trust in the firm decisions and
understandings reached here in community discussions, that either they
will be adhered to or that there will be prior notice and discussion
before any counter-decision is finalized. This is as much part of
stability and reliability as the code in the compiler and the libraries.
Thanks for being candid about this. I have difficulty, however,
picturing how to do a decision point better. At some point a decision
will be made. It's a judgment call, that in some reasonable people's
opinion, is wrong, and in some other reasonable people's opinion, is
right. For such, we're well past arguments' time - no amount of arguing
would convince. I don't see how to give better warning about essentially
a Boolean decision point that precludes pursuing the converse design path.
Andrei
