[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: First look at Guile Std Library available
From: |
Andreas Rottmann |
Subject: |
Re: First look at Guile Std Library available |
Date: |
Mon, 05 Jan 2004 01:30:44 +0100 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Richard Todd <address@hidden> writes:
>> (b)
>> what is the policy for changing an interface wrt backwards
>> compatibility? if you allow backward-incompatible changes, users
>> will learn to not trust the library (or at least allocate trust to
>> those elements that have changed in this way very begrudgingly). if
>> you disallow backward-incompatible changes, you need to be supremely
>> careful when defining interfaces for one-size-fits-all approach,
>> slightly less careful for pluralistic-menu.
>
> I agree with Dale Mellor's response. It's standard practice to stay
> compatible along minor version numbers, and OK to break backwards
> compatibility across major version numbers. This code base should
> grow over time, and the ideal organization and interface to the
> modules will certainly shift, even if we do get it perfect in the
> first place (which we won't, of course).
>
> What do you think of (std ...) => (std2 ...) as a means of letting
> older code run forever? I've read c++ is considering this approach.
> I don't think it should happen but every 5 years or so, and only then
> if backwards compatibility has become a burden.
>
Hmm, I always kind of disliked that approach.
1) It's probably very hard for a standard library (which presumably
consists of lots of modules) to stay API-compatible over an
longer period of time. Consider the GNOME project -- they have
the concept of the "GNOME developer platform", which will, given a
constant *minor* release number stay API compatible, but may (and
mostly will) break API every minor release number change, which
happens about every six months.
2) Presumed the need for API-breaking changes are needed, in turn not
to hinder development of the library itself, in intervals quite
smaller than 5 years, it would be more of a annoyance to developers
regularly adapting to the API changes (which indeed should only be
"major" in the sense that they require a lot of adaption to
existing code accross major version changes) to require changing
all their code to use stdY instead of stdX.
> I'm a little disappointed that all the response I've gotten has been
> about the library concept, and no one has yet appeared to be
> interested in the code I've put out there to date. Do you like it?
> Hate it? Don't care about it? Can it be that only
> Java/Python/Perl/Ruby need logging services, and scheme does not?
>
I just skimmed a bit over your code, and it seems quite OK. A few bits
I've noticed:
------- (logging logger) -----------
1)
,----
| (define (register-logger! str lgr)
| (if (not (string? str))
| (throw 'bad-type "Expected a string for the log registration"))
| (hash-set! all-loggers str lgr))
`----
Why not make GOOPS care for type-checking (given GOOPS is used)?
2) Have you considered the need for a "log domain" as in GLib? This
can be useful e.g. for an application to dump most logs including
all those generated by libraries into a file and present all logs
messages from its own domain and above a certain level in a special
way (e.g. message dialog).
Regards, Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Packages should build-depend on what they should build-depend.
- Re: First look at Guile Std Library available, (continued)
Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/03
- Re: First look at Guile Std Library available, Nic Ferrier, 2004/01/03
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/03
- Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/03
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/04
- Re: First look at Guile Std Library available, Thien-Thi Nguyen, 2004/01/04
- Message not available
- Re: First look at Guile Std Library available, Dale Mellor, 2004/01/04
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/04
- Re: First look at Guile Std Library available,
Andreas Rottmann <=
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/05
- Re: First look at Guile Std Library available, Robert Uhl, 2004/01/05
- Re: First look at Guile Std Library available, Richard Todd, 2004/01/05
- Re: First look at Guile Std Library available, Robert Uhl, 2004/01/05
- number->string radix patch (Was Re: First look at Guile Std Library available), Richard Todd, 2004/01/06
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Robert Uhl, 2004/01/07
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Richard Todd, 2004/01/07
- Re: number->string radix patch (Was Re: First look at Guile Std Library available), Robert Uhl, 2004/01/07
- I get unknown immediate error in guile 1.7, Roland Orre, 2004/01/08
- Re: I get unknown immediate error in guile 1.7, Roland Orre, 2004/01/08