Thinking about this a bit more, maybe a better approach it to
explicitly support versions?  Something like:

attach_function(:fancy_new_function, [], :int, :version => '1.1.0')

module FFI
  module Library
    def lib_version
      raise(RuntimeError, "You must implement #lib_version to support
function versioning")
    end
  end
end

Then modify attach_function to see check the passed in options for a
version, and if so, compare the specified version against the loaded
library version (via #lib_version).

The problem with this is FFI supports loading multiple libraries, so
the approach above is too simplistic since you would have need to
specify the version of which library in both #lib_version and in
#attach_fuction.

Charlie


On Sep 4, 3:19 pm, cfis <c...@savagexi.com> wrote:

> I've written a ffi wrapper for the free image library, which is here:
>
> http://cfis.github.com/free-image-ruby/
>
> The problem is that I've coded against the latest version of
> FreeImage, and most linux distributions have older versions
> installed.  Thus when I try to load the gem it fails since
> attach_function throws an error because the older versions don't have
> all the functions.
>
> This isn't what I want - the older versions work perfectly fine, they
> just don't include as much functionality.  So instead of blowing up, I
> would prefer if FFI throw a warning message but continue loading the
> library.
>
> If a user does call one of these unimplemented functions, then FFI
> should throw an error and allows the wrapping library to customize
> that message to say something useful (sorry, to use this function you
> need to upgrade to a newer version of freeimage).
>
> I can think of lots of ways of doing this, here is one possibility:
>
> * If a function is not implemented, instead of throwing an error, wrap
> it with a NotImplemented function (to go along with Function and
> Variadic).
>
> * When a NotImplemented function is called, throw an error.  This
> could:
>     - Just hard-code an error, not allow customization
>     - Call a method on library, not_implemented, that developers could
> override
>     - Call a proc which would be passed to attach_function which would
> be called
>
> I lean towards the 2nd choice, but don't feel very strongly about it.
>
> Does this sound like an idea that could be accepted to FFI?  If so,
> I'll code up a patch for review.
>
> Thanks - Charlie