[Top][All Lists]

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

Re: feature/integrated-elpa 4f6df43 15/23: README added

From: Alain Schneble
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Wed, 19 Oct 2016 22:57:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt)

address@hidden (Phillip Lord) writes:

> Alain Schneble <address@hidden> writes:
>> But don't get me wrong.  I really don't think this will be the usual
>> case.  In most if not all packages, accounting for such misuses won't be
>> required at all.  I just wanted to prove it's not an unsolvable problem.
> I like this, and it gives a nice error message of deprecation, and I
> think that is good. But this is a solution which requires package
> developers to explicitly support declarations of deprecation.

Indeed.  But in case a package offers a public feature/interface to be
used by anybody, including non-package code, such an explicit handling
would be TRTTD, IMO.

> Just removing "food-package-1.0" from `load-path` gives a less nice
> error message, but it still fails fast, and requires no developer
> support

True.  But I don't think we have to account for all possible "misuses"
and bugs.  We all run into issues.  But we have to try to not get biased
by a specific problem one once had and which might have taken hours to
fix, if after all it's clearly a "usage error" or -- depending on how
you see it -- in your case a deprecation of a public functionality in a
package that wasn't flagged as deprecated in the first place, before
actually having been removed.  Emacs is more like a white box.  You will
always find dozen of ways to break something.  But we shall not
primarily focus on such edge-case scenarios, I think.

And I think this discussion has nothing to do with the directory layout.
It's a different topic IMO, though you try to fix it with the directory


reply via email to

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