This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: interface reductions


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> The primary objective for Guile is to be useful.  While I agree that
> we could construct a better API for fluids, we should not remove
> functionality until this has been implemented.  It is probably a good
> idea to write a warning that these macros might *become* deprecated in
> the future, both in comments and in the manual.

[...]

> In the general case, we can't deprecate things until there exists some
> substitute.  There should always be a valid alternative.  That is,
> when we mark something as "deprecated", we should be able to say how
> the (currently) real solution looks like.

The philosophy here is that there is always a cost involved in a
change, both for the implementor and for the users.  Therefore, we
should try to wait to change things until we have a solution which
has high quality and will be long-lasting.

I think you agree with this.  But we seem to have a different
interpretation of "deprecated".  If I, as a programmer, see that
something is deprecated, that means, for me, that A. I should not use
it in new programs, ans B. I should try to remove it from old programs
when I get the opportunity.  But I can't do that if there doesn't
exist a valid alternative.

But it could of course still a good idea to warn people about
something that might become deprecated.

Also, in some cases we actually *should* consider removing
functionality, if the cost of the functionality, in terms of
restricting our implementation, is too large in relation to the
usefulness of the feature.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]