Re-implement boolean methods for custom type return

[danielpclark]

As per @dubek 's #67 suggestion I've researched and found in the FFI spec we can return custom types. See custom_type_spec.rb

We'll match the types to the way Ruby already does. This will be new behavior so we'll set this to release version 0.2.0

[danielpclark]

My thoughts quoted from the other thread on dealing with multiple types

Rust allows only 1 type to be returned and FFI even more so expects one type to be returned. To model multiple types we have to create our own type, which will wrap both types, which we can do in both Rust and FFI with Structs.

But then thinking about how to handle the struct in Ruby we might be adding something like raise struct.error if struct.error otherwise return struct.value . That Ruby conditional will likely cost us lots in performance

I'm not sure how deeply coupled the FFI lib is within the code that is written in itself. For example we can do callbacks which lets us evaluate a block in another call to "Rust" but still has the original method returning a type... which should be of one type of return.

I think the issue really comes down to how much we can cheat the one return type design and how much FFI will let us conditionally return that value without higher level Ruby code evaluating that condition.

[danielpclark]

If there is a noticeable performance hit on this it may be thrown out.

[danielpclark]

Here's an idea on hacking performance and allowing error messages without using Structs but using callbacks. This example would allow us to work with anything and not just boolean values. This is not working code, just for example.

def ruby_method_for_rust_implementation
  vals = [nil, TypeError]
  rust_thread_callback = RustThread.new { some rust callback thread pointer }

  vals[0] = FFI_call_to_rust_method(parameters, rust_thread_callback)  

  # vals[0] or vals[1]
  vals[rust_thread_callback.result]
end

This is assuming that an array index is faster than an if condition. Also I'm a little unconformable with threads but as we're hopping between code bases it might be a good idea. It might be a very bad idea.

[danielpclark]

I'll leave FasterPath methods with the same behavior. If new behavior is needed for monkey-patches or refinements we'll just write alternative methods for those.