From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Todd Newsgroups: gmane.lisp.guile.user Subject: Re: First look at Guile Std Library available Date: Sun, 04 Jan 2004 23:00:33 -0600 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <3FF8EF71.6090802@vzavenue.net> 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> <87isjr1bkb.fsf@alice.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1073279450 6058 80.91.224.253 (5 Jan 2004 05:10:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 05:10:50 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 05 06:10:47 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 1AdN0p-0001gC-00 for ; Mon, 05 Jan 2004 06:10:47 +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 1AdNxZ-0003uK-Ey for guile-user@m.gmane.org; Mon, 05 Jan 2004 01:11:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdNqs-00019k-NA for guile-user@gnu.org; Mon, 05 Jan 2004 01:04:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdNpb-0000jl-4H for guile-user@gnu.org; Mon, 05 Jan 2004 01:03:46 -0500 Original-Received: from [66.171.59.140] (helo=smtp.vzavenue.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdNpa-0000iO-6Q for guile-user@gnu.org; Mon, 05 Jan 2004 01:03:14 -0500 Original-Received: from vzavenue.net (42.157.171.66.subscriber.vzavenue.net [66.171.157.42]) by smtp.vzavenue.net (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id BCD32277; Mon, 5 Jan 2004 00:01:40 -0500 (EST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en Original-To: Andreas Rottmann In-Reply-To: <87isjr1bkb.fsf@alice.rotty.yi.org> 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:2524 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2524 Andreas Rottmann wrote: > Hmm, I always kind of disliked that approach. > > 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. You could be right. I was thinking along these lines: There is a lot that can be done to preserve compatibility over a period of time, that essentially builds up cruft in the library. Things like leaving the old function name _and_ the new function name in. Things like moving the module _and_ leaving a module in the original location to load it, too. Things like adding the second XML processing module but leaving the original one there too. Then, (I was hoping only once every few years), you have to say "Enough!" and break with the past. It could be that it's best to do something in-between, and let small incompatibilities in over time, and reserve std2 for a massive reorganization. Some people do a "deprecate-for-1-major-release" strategy, after which deprecated things disappear. That might be an option also. > 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)? Good question! I'll do this. > 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). Not familiar with GLib, but if you mean that different parts of the program talk to different named 'domains', then that you should be able to get something similar with the register-logger! mechanism, right? You could log to as many named loggers as you want. You can even assign the same handlers to different named loggers. So, your "gtk" logger could be sending its logs to the same files as your "app" logger, for instance. I may not fully understand the domain concept, yet, though. thanks, Richard _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user