Jack Unrue wrote: > On 12/19/06, Luís Oliveira <[EMAIL PROTECTED]> wrote: >> >> I've added this to the TODO list. I've also thought a little about how >> to support this best, API-wise. Besides the obvious :LIBRARY (or some >> other name) to DEFCFUN and friends it'd be nice if CFFI could infer >> the "current library" somehow. An IN-FOREIGN-LIBRARY macro for >> instance, though that might break when doing incremental development >> with SLIME for instance. > > Yeah, I see what you're getting at. Otherwise, I guess one has to encode > context into the Lisp name of each function, sort of like I did in my > DllGetVersion example. > >> DEFINE-FOREIGN-LIBRARY could record the library name's symbol-package >> and then DEFCFUN could look at *PACKAGE* to figure out which DLL to >> use. That might be a silly idea. > > I don't know about silly :-) but I would vote against that option if it > were > to be the only solution. Even though I can imagine use-cases where that > might be reasonable, it's not a natural thing to do. C++ programmers are > not required to declare a new namespace for each DLL that they use, > for example. > >> This kind of mechanism (either this last one, or an >> IN-FOREIGN-LIBRARY, or >> something else) would also be useful for library-wide settings such >> as stdcall vs. cdecl. That's actually the context in which I had >> thought about this. >> >> I'm sure this kind of problem has been dealt with before in other >> libraries (IIRC, five-am has an IN-SUITE macro). Any ideas? > The package solution doesn't seem that silly to me --- an additional namespace doesn't seem like a huge price to pay. An alternative encapsulation method would be to use CLOS and locate different entry points relative to an object that corresponds to the library. I guess the choice would depend on whether you prefer namespaces or objects.
-- Robert P. Goldman Senior Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 384-3454 Email: [EMAIL PROTECTED] _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
