Is it possible to think too highly of Moose? Most of what I want in a deprecation policy is in Moose's deprecation policy. Loosely rephrased (so believe the official published Moose policy, not my interpretation of its words):
- It's better to do things right than to do things the way everyone's always done them previously.
- Undocumented behaviors are unsupported behaviors. They can and will break.
Consider technologies which lack defined upgrade, version, and obsolescence paths: Microsoft Windows, SMTP, PHP, the JVM.
Consider technologies which have defined upgrade, version, and obsolescence paths: Perl 6, Moose, the Linux kernel.
Which would you rather use? Java the language has the patina of type safe
collections, but Java bytecode (apparently) can't change to support real type
safety. PHP has never met a half-baked feature-adding patch it doesn't like,
even if that patch gets in the way of something better a few years in the
future. (I half expect PHP 6 to restart development by adding drive letters as
namespace anchors, say C:\This\is\my\PHP\Namespace.) Various
Windows kernels have included workarounds for bugs in specific DOS programs and
16-bit Windows programs.
I suppose if you see programming as an occasional exercise where you blurt out a few pages of code and spend the rest of your life hoping never to touch that machine again, there's value in nothing ever changing (though here's the source code to old versions; go crazy).
Meanwhile, if the price I pay for using Moose or Perl 6 or whatever is that I need an explicit declaration of the version I intend to use and I need to pay attention to upgrades but in return my code gets a little faster, a little cleaner, and a little more correct, that seems like a bargain. After all, I use these tools because they make me more productive. Why would I limit myself with the baggage of having to support accidental, undocumented features used by code I can't even prove exists?
(The Parrot world once had a brief debate over whether our deprecation policy covered the names and orders of struct members in Parrot's C data structures. Imagine wanting to clarify the name of a variable and having to wait three months even if accessing that code from outside of libparrot represented an egregious violation of encapsulation so much that you'd have to copy and paste literal source code between files. The flip side of the "Sane deprecation is good" argument is "Design and document an effective API". Then again, you have to be able to recognize insane APIs, which is not an easy task when you have Stockholm Syndrome from suffering under the reign of actively hostile interfaces.)
