From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Mon, 05 Jan 2004 01:30:44 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <87isjr1bkb.fsf@alice.rotty.yi.org> References: <20040102052128.GA16849@Richard-Todds-Computer.local> <87wu89q8pj.fsf@kanga.tapsellferrier.co.uk> <20040103221857.GA518@Richard-Todds-Computer.local> <20040104035022.GA742@Richard-Todds-Computer.local> <3FF88AD5.6010701@vzavenue.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073262811 17103 80.91.224.253 (5 Jan 2004 00:33:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 00:33:31 +0000 (UTC) Cc: guile-user@gnu.org, ttn@glug.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 05 01:33:28 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdIgS-0000uH-00 for ; Mon, 05 Jan 2004 01:33:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdJcm-0001nf-KP for guile-user@m.gmane.org; Sun, 04 Jan 2004 20:33:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdJcB-0001lm-Tn for guile-user@gnu.org; Sun, 04 Jan 2004 20:33:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdJbe-0001Re-UG for guile-user@gnu.org; Sun, 04 Jan 2004 20:33:06 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.24) id 1AdJbe-0001Pf-Ct for guile-user@gnu.org; Sun, 04 Jan 2004 20:32:34 -0500 Original-Received: (qmail 5455 invoked by uid 65534); 5 Jan 2004 00:31:04 -0000 Original-Received: from chello213047125140.14.univie.teleweb.at (EHLO garibaldi) (213.47.125.140) by mail.gmx.net (mp025) with SMTP; 05 Jan 2004 01:31:04 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.30) id 1AdIdp-00024w-Bt; Mon, 05 Jan 2004 01:30:45 +0100 Original-Received: from andy by ivanova with local (Exim 4.30) id 1AdIdo-0000Ak-LS; Mon, 05 Jan 2004 01:30:44 +0100 Original-To: Richard Todd In-Reply-To: <3FF88AD5.6010701@vzavenue.net> (Richard Todd's message of "Sun, 04 Jan 2004 15:51:17 -0600") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-Spam-Score: -4.9 (----) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2521 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2521 Richard Todd 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