On Thu, Dec 25, 2008 at 9:22 PM, Attila Lendvai <span dir="ltr"><<a href="mailto:attila.lendvai@gmail.com">attila.lendvai@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> May I suggest having a xcvb:*find-modules* var (or similar) that contains a<br>
> list of these functions (or<br>
> symbols to these functions perhaps) so that instead of just adding new<br>
> pathnames, we can add<br>
> functions to find lists of these pathnames. They could optionally accept a<br>
> module name in case the searching module can use the information to narrow<br>
> the search better.<br>
<br>
<br>
</div>+1 from here, modulo details, naming, etc.</blockquote><div><br>The naming isn't important to me either. Neither are a lot of the details :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
i've never liked the static *system-registry* with the manual<br>
symlinking on the filesystem. using a directory scanner yields a much<br>
pleasing user experience for me. so, please make the functional way<br>
the default or the first in the docs to advertise it for the<br>
newcomers...<br>
</blockquote><div><br>Well, I wasn't thinking about it as something incompatible; I'm talking about implementing the suggested search system in an extensible way. Something like this:<br><br>(defvar *module-finders* '(find-in-home find-in-environ find-in-sys find-on-http))<br>
(defun find-in-home (id) "Searches ~/.xcvb/systems for ID" ...) <br>(defun find-in-environ (id) "Searches $XCVB_SYSTEMS env" ...)<br>(defun find-in-sys (id) "Searches /usr/lib/xcvb/systems for ID" ...)<br>
(defun find-on-http (id) "Searches various websites for xcvb systems" ...)<br></div></div><br>Such that it would implement the suggested default path, but specifically export *module-finders*<br>so that instead of merely setting *system-registry* (or similar), we can push something interesting<br>
onto module-finders to do a local (or packaged) search; For example, my application which ships with its own dependencies might push on a function which prefers the included files, or when porting an app from sbcl to ecl (or whatever), I might find i want to change the "home" of some modules on an ad-hoc basis so I can use an older version of a particular module, without having to move files around on the disk.<br>
<br>Originally I was thinking the finders would return a list of pathname objects, and that network-methods would use a cache. This would also make implementing (modules-apropos) or something, easier.<br><br>I've thought more since then:<br>
<br>The finders could return some object that we could interact with using:<br><br>(defgeneric finder-get-more-findees (what))<br>(defgeneric findee-get-definition (found))<br><br>Where "what" was returned by one of the functions listed in *module-finders* (to implement lazy lists- perhaps just a list and a generating function would be enough...), and "found" is one of the members of "what".<br>
<br>"found" would usually be a pathname (in which case, findee-get-definition would open, read it, and return the definition), but it could also be other things- perhaps a network socket or some rows from an sql database.<br>
<br>Once a defintion had been read, xcvb would have to check to make sure it was actually the desired module; The finders would be able to assume ID was just a substring to give searching and retrieving a common interface, but by allowing ID to be T (all systems) we could mirror/cache all systems easily, or debug the search tree easier.<br>
<br>Of course, this still supports the search path you outlined previously.<br><br>Also, if the found object is dynamically dispatched, different module file formats could be implemented by a special loader, and (more interestingly) :around methods could be used to dynamically process the defined systems (instead of having to edit or fork the definition files). I don't know how valuable this would be to others though.<br>