[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First look at Guile Std Library available

From: Richard Todd
Subject: Re: First look at Guile Std Library available
Date: Sun, 04 Jan 2004 23:00:33 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

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.


| (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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]