F. Senault wrote:
> Le 11 fñ×rier 2009 22:53, Alex Fenton a ñÄrit :
>   
>> But this misses the main point - that there is no assurance that code 
>> developed using 1.8.7 (or 1.8.8) will run on 1.8.6. And no way of 
>> checking, other than scrutinising the ChangeLog. This is a huge 
>> disservice to library authors and users.
>>     
> Something like :
>
> require "compat-1.9"
>
> Object.new.tap { |o| p o }
>
> I guess that it's a lot of work if it's implemented in C,

I don't see why it would be -- wouldn't be the first C extension -- but 
it's possbile I just don't understand the issue.

Regardless, many of these are just trivial.

class Object
  def tap
    yield self
    self
  end
end

class Symbol
  def to_proc
    proc {|x| self.send(x) }
  end
end

There are a few, like public_send (which I really should be using there) 
-- actually missing from 1.8.7, but I've actually got my own implemented 
somewhere. In fact, the above don't really even need to be aware of 
version numbers -- just something like:

unless Object.new.respond_to? :tap
  class Object
    def tap
...

unless :to_proc.respond_to? :to_proc
  class Symbol
    def to_proc
...

That would allow such libraries to be distributed as gems, and they'd do 
no harm if run under 1.9 -- if there's already a C version in place, use 
that, otherwise, add our own ruby version.

In fact, this is already how I develop things. I test on 1.8.7 and 
1.9.1, but anything I build should work on 1.8.6 as well -- so far, 
there's been nothing added to 1.8.7 that can't be added to 1.8.6 as 
well, using plain old Ruby.