Abdulaziz Ghuloum <aghuloum@xxxxxxxxx> writes: > On Oct 1, 2009, at 6:59 PM, GÃran Weinholt wrote: > >> So is the idea that I would be keeping versioned filenames in my >> bazaar >> repository, or would they be renamed to include a version by a package >> manager? > > We should not assume the existence of a package manager. Also, you > won't be using a package manager when working with your own libraries, > right? Usually, you work on your libraries locally and then, in a > separate step, package it together for distribution. You won't want > to add the package manager to your workflow. That's a good point. So what problem is solved by keeping the version inside the filename? I read something about a distinct mapping of filenames to library names, but then I'm not sure what problem that in turn solves. If you want the version number then it's in the file, which is usually not far away. Having the version in the filename also duplicates information, which in my experience always gives you the problem of keeping the duplicated information synchronized. Obviously the library name is duplicated in the filename, but it changes much less often than the version number. There is something of a feature-creep in this SRFI as it currently stands. As I see it, the idea is to standardize the widely implemented library file locator algorithm and work out all the edge cases. Keeping the version number in the filename is not widely implemented, and creates new problems by itself. Remove that feature and I think we will have a less controversial SRFI that is also compatible with existing Schemes and libraries. I'm all in favor of library versions and version references. I use them myself, as a courtesy to those who want to use my libraries, and because I want to be able to change the meaning of exported bindings without causing people too much trouble. Is the idea that filenames should contain versions so that multiple versions of a library can co-exist in the same directory? If a library developer wants to do that, he can simply append a major version to the end of a library identifier, something like this: (foo jpeg (0)) foo/jpeg.sls initial version (0 is the minor) (foo jpeg (1)) foo/jpeg.sls second version, supports more formats (foo jpeg1 (0)) foo/jpeg1.sls third version with a much better API If he wants to he can even make it so (foo jpeg) is a compatibility wrapper around (foo jpeg1). Such a wrapper would be very useful for anyone changing a program to use the new library, because it would show exactly what changes are necessary. And if the developer was careful, there will not be any point in keeping (foo jpeg (0)) around when you've got (foo jpeg (1)). This is much less tedious than requiring that every part of a version reference always must be included in the filename, and it leaves the individual developer free to choose what he and his users need. I can't imagine anyone being very happy when they discover that to use R6RS's version feature they need to forever keep renaming their files. >> Also, SCHEME_LIBRARY_SEARCH_PATHS is rather long. How about SLSPATH? > > I think it is long. I'd be happier with SCHEME_PATH (Derick likes > plurals and hates unix) or SCHEME_LIBRARY_PATH. The work SEARCH is > definitely not adding anything you don't already understand from the > word PATH. I completely agree. Your proposed names are much more idiomatic. Regards, -- GÃran Weinholt <goran@xxxxxxxxxxx> "... for these truths hold good for everything that is ..."
Description: PGP signature