Discussion: Why is inet_addr in IO?
John Lato
jwlato at gmail.com
Sun Aug 31 23:30:36 UTC 2014
On Mon, Sep 1, 2014 at 12:47 AM, Gregory Collins <greg at gregorycollins.net>
wrote:
>
> On Thu, Aug 28, 2014 at 1:31 PM, Thomas DuBuisson <
> thomas.dubuisson at gmail.com> wrote:
>
>> I fully support directing users to getAddrInfo. My comment boils down
>> to: let's remove broken functions instead of making them easier to use
>> and less consistent with the rest of the API.
>>
>
> Only if we run a deprecation cycle for at least one major version of
> network. Just removing a function breaks code for no reason and is
> user-hostile. It's important to give end users a warning that the function
> is going away and some time (12 months or more IMO) to fix their code,
> especially for packages that belong to the platform.
>
Why bother? Nobody ever does this now, so there's no good reason to start.
It only wastes a little bit of end-use time, all they have to do is dig
through docs and/or commit messages (or maybe a changelog message, if
someone can be bothered to write one) to see if there's a useful
replacement mentioned.
Seriously, I'm strongly in favor of both removing broken-ness and
deprecation cycles. Every time we update our library stack I have to go
through this, and every time I run across 4 or 5 libraries (minimum) with
functions disappearing out from under us. Even top-20, supposedly
well-maintained packages are guilty.
John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140901/25be59c8/attachment-0001.html>
More information about the Libraries
mailing list