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