Re: [clisp-list] critique of default-foreign-language & API design questions

[Sam S. <sd...@gn...>]

> * In message <DFD875E85664D3118FA6080006277DE7055A0784@U8PN2.blf01.telekom.de>
> * On the subject of "[clisp-list] critique of default-foreign-language & API design questions"
> * Sent on Wed, 17 Apr 2002 11:30:59 +0200
> * Honorable "Hoehle, Joerg-Cyril" <Joe...@t-...> writes:
>
> I'm considering changing dynload.d's
> # (FFI:RESOLVE-FOREIGN-NAME name lib &optional os-option)
> into
> (LOCATE-FOREIGN-VARIABLE name lib) and
> (LOCATE-FOREIGN-FUNCTION name lib)

Or no!! Please don't!!
there will be a lot of code duplication between your
LOCATE-FOREIGN-FUNCTION and LOCATE-FOREIGN-VARIABLE.

Please make the optional os-option a _required_ argument instead:
        (FFI:RESOLVE-FOREIGN-NAME name lib type)
where type is is either :FUNCTION or :VARIABLE

> FUNCTION vs. VARIABLE only makes a difference on platforms
> with HAVE_SHL_LOAD (HP/UX). It doesn't make a difference on
> other platforms (dlopen(), MS-Windows etc.). There sysdll's
> dll_function() and dll_variable() map to the same call.
> 
> My goal is to have programmers on the other platforms easily
> (and reliably) write code that will work there too
> -- without crashes or changes.
> 
> Programmers on the other platforms will tend to forget about
> the extra parameter to RESOLVE-FOREIGN-NAME, partly because they
> may not recognize the importance of a difference not visible to them,
> partly because their code will work in any case.
> So their testing doesn't show bugs.
> 
> With LOCATE-FOREIGN-FUNCTION/VARIABLE however, the situation is
> completely different.
> By sole virtue of the name, programmers on any platform will notice
> that there's something wrong should they happen to write (or read):
> 
> (ensure-foreign-FUNCTION
>   (or (locate-foreign-VARIABLE "compress" "zlib")
>       (error "not found"))
>   '(c-function (:arguments #) #))
> 
> That's how I could "show by example" that API design *has* an
> influence on the robustness and liability of software to crash
> after the next patch or next port.

this is handled by making the last arg required too.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
History doesn't repeat itself, but historians do repeat each other.