Re: Unwanted hook names (was Re: interface reductions)

[cwitty at newtonlabs dot com (Carl R. Witty)]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> So I have to agree with you that this is extremely bad.  But, the only way
> we could cause a compile time error would be to either rename
> scm_create_hook or change it's parameter list.
> 
> So, what to do about this problem:  It's not too bad of an idea to say
> that functions with changing behaviour get renamed.  But, if the name was
> quite allright, you wouldn't like to do this.  And, you change something
> again, and the next release you change the name back again.  Hmmm?
>
> Does someone have a good idea how to solve this problem?  Maybe, a run
> time warning about changed behaviour written to stdout whenever a function
> with changed behaviour is called?  (This, certainly, only when
> SCM_DEBUG_DEPRECATED=1).  But, this leaves the risk that by coincidence
> the function is not called, and the bug remains undetected.
> 
> I'd very much like to hear suggestions about how to solve this elegantly.

Sorry, I can't think of an elegant solution.  If we want to be able to
check for an application's use of deprecated or soon-to-change
functionality by enabling compile-time error messages, I think we have
to rename the function.  (The other possibility is to put a notice in
the NEWS file: "WARNING: The following functions have changed in a
backward-incompatible way.  1) scm_create_hook no longer protects the
hook it creates.")

Two additional arguments in favor of changing the name: some packages
(I'm thinking of scwm in particular here, but there are probably
others) try to work with several different versions of guile, by using
the autoconf machinery to check for the presence or absence of certain
functions in the guile library.  This approach fails if the meaning of
a function changes without renaming the function.  Also, if you're
using a shared library mechanism, changing the meaning of a function
without renaming it means that you can't run old binaries against new
shared libraries.

> > 2) With your change, guile itself (rather than some other project
> > which uses guile) must be compiled with SCM_DEBUG_DEPRECATED=1.
> 
> I don't think that this is true:  Guile itself will work either with or
> without SCM_DEBUG_DEPRECATED=1, however, with SCM_DEBUG_DEPRECATED=0 an
> additional redundant protection is performed, but this is not a problem.

I see I didn't explain myself well.

I meant that it was my understanding that SCM_DEBUG_DEPRECATED would
affect only the compilation of a package using guile, not the
compilation of guile itself.  (I.e., defining SCM_DEBUG_DEPRECATED
during the compilation of guile would not change libguile.a.)  I think
this is a good goal.

If this goal is met, and somebody is developing an application which
uses guile on, say, Debian or Red Hat, then she can simply use a
precompiled guile package provided by the distribution.  If this
person wants to check whether she is using deprecated features, she
can recompile her own application while defining SCM_DEBUG_DEPRECATED.

On the other hand, if a full deprecatedness check involves running
your application against a libguile compiled with
SCM_DEBUG_DEPRECATED, then our hypothetical developer's task becomes
much more difficult.  She must download and recompile a private
version of guile, and figure out how to privately install it in such a
way that she can switch back and forth between linking against this
private version (for SCM_DEBUG_DEPRECATED builds) and the public
version (for normal builds).

Granted, this is not terribly difficult; but I fear that it's hard
enough that most people would not bother, thus rendering
SCM_DEBUG_DEPRECATED significantly less useful.

Carl Witty