Re: First look at Guile Std Library available

[Andreas Rottmann]

Richard Todd <address@hidden> 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         | address@hidden      | address@hidden | address@hidden
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.