|
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.
<snip>
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.
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.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).
thanks, Richard
[Prev in Thread] | Current Thread | [Next in Thread] |