guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: And another deprecation joke


From: David Kastrup
Subject: Re: And another deprecation joke
Date: Wed, 07 Dec 2011 16:30:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Wed 07 Dec 2011 13:58, David Kastrup <address@hidden> writes:
>
>> `dimensions->uniform-array' is deprecated.  Use `make-typed-array' instead.
>>
>> Unfortunately, this was not even called in the application.
>>
>> The actual function called was make-uniform-vector.
>
> Ah, interesting.
>
> You might not be a native english speaker; I don't know.  However, the
> proper word is "bug", not "lie" or "disrespect".

Few people are native speakers: that capacity is usually acquired later
in life.

While I can't claim this status, I don't find that

    This, however, is a bug, since there is no place above where
    "vectag" would be explained.

and particularly

    This is not the first such "deprecation" I have encountered, and it
    shows a blatant bug of the user base.

are convincing replacements.  In the first case, "falsehood" would be a
less loaded term for the same situation.  In the second, "disregard".
And I am afraid it does not get less loaded than that.  The source of
information for users is the documentation.  Changing or adding code and
not documenting it does not cater to users' but to developers' needs.

And it is not like I go hunting for nitpicks.  I try using Guile, and
those things hit me right in the face.  The "deprecation warnings" are
_explicitly_ coded, and obviously nobody bothered checking even
superficially that the user-available documentation documented the
specified replacements.

Whatever procedures lead to that result, it does not appear that they
have working policies or mechanisms that would ascertain either end user
viability (since the end user gets to see the respective deprecation
warnings) or application programmer viability (since the application
programmer is responsible for doing the code replacements).

So when I talk about "shows a blatant disrespect", this does not locate
the source of that disrespect which can also be inherent in the
procedures leading to such results.

It would appear to me that the procedures related to deprecation of
functions could likely make use of some amendments leading to more
consistent usability of the results.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]