From: Andreas Rottmann <a.rottmann@gmx.at>
Cc: guile-user@gnu.org, ttn@glug.org
Subject: Re: First look at Guile Std Library available
Date: Mon, 05 Jan 2004 01:30:44 +0100 [thread overview]
Message-ID: <87isjr1bkb.fsf@alice.rotty.yi.org> (raw)
In-Reply-To: <3FF88AD5.6010701@vzavenue.net> (Richard Todd's message of "Sun, 04 Jan 2004 15:51:17 -0600")
Richard Todd <richardt@vzavenue.net> 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 | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at
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.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2004-01-05 0:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-02 5:21 First look at Guile Std Library available Richard Todd
2004-01-02 9:29 ` Dale Mellor
2004-01-03 1:03 ` Richard Todd
2004-01-03 2:25 ` Andreas Rottmann
2004-01-03 15:00 ` Dale Mellor
2004-01-03 14:36 ` Dale Mellor
2004-01-03 22:42 ` Richard Todd
2004-01-03 16:38 ` Thien-Thi Nguyen
2004-01-03 16:48 ` Nic Ferrier
2004-01-03 22:18 ` Richard Todd
2004-01-04 1:49 ` Thien-Thi Nguyen
2004-01-04 3:50 ` Richard Todd
2004-01-04 12:59 ` Thien-Thi Nguyen
[not found] ` <16376.5782.10995.206284@l.a>
2004-01-04 14:17 ` Dale Mellor
2004-01-04 21:51 ` Richard Todd
2004-01-05 0:30 ` Andreas Rottmann [this message]
2004-01-05 5:00 ` Richard Todd
2004-01-05 16:03 ` Robert Uhl
2004-01-05 20:01 ` Richard Todd
2004-01-06 1:36 ` Robert Uhl
2004-01-06 18:41 ` number->string radix patch (Was Re: First look at Guile Std Library available) Richard Todd
2004-01-07 4:04 ` Robert Uhl
2004-01-07 5:26 ` Richard Todd
2004-01-07 20:54 ` Robert Uhl
2004-01-08 7:11 ` I get unknown immediate error in guile 1.7 Roland Orre
2004-01-08 17:14 ` Roland Orre
2004-01-10 20:17 ` Kevin Ryde
2004-05-10 20:34 ` number->string radix patch Marius Vollmer
2004-05-11 3:16 ` Richard Todd
2004-05-11 3:51 ` Keith Wright
2004-05-27 21:56 ` Kevin Ryde
2004-06-10 16:35 ` Marius Vollmer
2004-06-10 16:34 ` Marius Vollmer
2004-05-11 5:23 ` Richard Todd
2004-05-27 21:54 ` Kevin Ryde
2004-06-10 16:47 ` Marius Vollmer
2004-06-11 1:40 ` Kevin Ryde
2004-01-05 10:08 ` First look at Guile Std Library available Dale Mellor
2004-01-05 3:39 ` Paul Jarc
2004-01-05 4:28 ` Richard Todd
2004-01-05 5:19 ` Paul Jarc
2004-01-06 22:25 ` Ludovic Courtès
2004-01-06 23:53 ` Richard Todd
2004-01-16 20:17 ` Andy Wingo
2004-01-05 14:00 ` Thien-Thi Nguyen
2004-01-05 20:32 ` Richard Todd
2004-01-05 20:59 ` Dale P. Smith
2004-01-06 16:54 ` Thien-Thi Nguyen
2004-01-06 20:32 ` Richard Todd
2004-01-03 18:19 ` Clinton Ebadi
2004-01-03 20:12 ` Thien-Thi Nguyen
2004-01-04 2:02 ` Richard Todd
2004-01-06 20:42 ` Richard Todd
2004-01-06 21:20 ` Paul Jarc
2004-01-03 22:52 ` Richard Todd
2004-01-04 1:53 ` Thien-Thi Nguyen
2004-01-04 20:34 ` Arno Peters
2004-01-05 20:12 ` Richard Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87isjr1bkb.fsf@alice.rotty.yi.org \
--to=a.rottmann@gmx.at \
--cc=guile-user@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).