Re: changing function signatures and no library version # => must use too-general test

[Miles Bader <miles.bader@necel.com>]

"Drew Adams" <drew.adams@oracle.com> writes:
>     Some functions are known to be "exported"
>
> I don't know what you mean here. Do you mean documented in the manual?
>
>     in which case we have to be
>     careful, which is already a pain in the _|_ at times, but if we start to
>     have to be careful like that with each and every function, it's
>     going to be *really* annoying.
>
> Annoyance to developers is important, but it is not as important as clean
> software and clear software maintenance.

Elisp doesn't have a well-defined notion of interfaces, so it's
_possible_ that just about any random "internal" function will get
called by an external package.  However it would be completely absurd to
try and maintain absolute compatibility for _every_ function.

So it ends up being a judgement call:  If I judge a function to be
"internal" (and no evidence that people are using it despite that), then
I can decide to put the burden on external packages (to fix their code)
rather than on myself (to do the additional work and add the additional
cruft required for maintaining compatibility).  If I judge a function to
be "an interface", I will likely put the burden on myself.  I think this
is fair tradeoff.

If one is writing an external package, there are some vague clues one
can use to avoid problems -- as you suggest, if it's documented in the
manual, it's probably thought of as some sort of official interface, and
is less likely to be changed incompatibly; if it doesn't even have a
doc-string, it's likely thought of as an internal function.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."