[Gdal-dev] SWIG / TestCapability / Ruby

[Kevin Ruland]

Hi guys,

Sorry I wasn't following this thread too closely until now.  In many of
the script languages, it doesn't really matter what we return because
they silently coerce from one type to the other.

I gotta say, it's very wierd of ruby to treat 0 as true.  In fact, one
might really question it's sanity.  Anyway,  this is what I suggest we do:

in the top of the binding declare:

typedef int BOOLEAN;  /* Or whatever we decide to call this shadow type */

Then change all the declarations of functions which follow this:

BOOLEAN testCapabilities();  /* or TypeIsComplex() */

Then each langague wrapper need to implement the proper

%typemap(ret) BOOLEAN {

  $result = PyLong_fromInt( $1 );

}

Or in the case of ruby:

%typemap(ret) BOOLEAN {

  if ($1 == 0) {
    $result = ruby_nil();
  }
  else {
    $result = ruby_one();
  }
}

The "type" BOOLEAN never really exists, it's just an indicator to apply
the proper typemap.

We've used this trick before with a typemap called IF_FALSE_RETURN_NONE.

Kevin

Charlie Savage wrote:

> The various TestCapability methods in OGR have a return type of
> integer.  However, if you read the OGR C API documentation its says:
>
> "Returns: TRUE if the layer has the requested capability, or FALSE
> otherwise. OGRLayers will return FALSE for any unrecognized
> capabilities."
>
> So it seems like the intent it to return a boolean.  In C-like
> languages returning an int is ok, since 0 evaluates to false.
>
> This however, is not the case in all languages.  In Ruby, for example,
> false is either nil (same as NULL or PyNone) or false.  Thus the value
> 0 does *not* evaluate to false.  That means you can't do something
> what is natural:
>
> if lyr.test_capability( 'FastGetExtent')
>
> It will always evaluate to true in Ruby!
>
> I would like to change the SWIG wrapper code so that all the
> testcapability methods return booleans.  I think this is ok, since the
> bindings are built using SWIG's C++ mode, so boolean is a supported
> data type.  That way I don't have to put in a separate mapping for
> these methods just in the Ruby bindings.
>
> Thanks,
>
> Charlie
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev