HTTP:Post and Ruby 1.8.2

It seems HTTP:Post was changed a bit in 1.8.3+

I have publicly available code and I’d like it to support either Ruby
version.

Should I actually check the Ruby version? How would I actually do that?
None of my searches paid off.

Alternatively, I could catch the ‘NoMethod’ exception, but that would
mean
it could potentially take the 1.8.2 code path if I actually goofed a bit
in
my 1.8.4 path.

_jason

On Apr 28, 2006, at 7:58 PM, Jason P. wrote:

Should I actually check the Ruby version? How would I actually do
that?
None of my searches paid off.

Should you? That’s debatable. Could you? Absolutely.

% ruby -e ‘p VERSION’
“1.8.4”

On 4/28/06, Logan C. [email protected] wrote:

% ruby -e ‘p VERSION’
“1.8.4”

while I guess I could call eval and get that, is there a way to check
the
ruby version at runtime? A global var or something?

I’ve decided to just change my code to something that works in both
versions, but I’m still curious how to do this :slight_smile:

_jason

Jason P. wrote:

On 4/28/06, Logan C. [email protected] wrote:

Should you? That’s debatable. Could you? Absolutely.

% ruby -e ‘p VERSION’
“1.8.4”

while I guess I could call eval and get that, is there a way to check the
ruby version at runtime? A global var or something?

Yes. See the example above.

:slight_smile:


James B.

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://refreshingcities.org - Design, technology, usability

On Apr 28, 2006, at 8:22 PM, Jason P. wrote:

_jason

Perhaps my example wasn’t clear:

#!/usr/bin/env ruby
if VERSION >= “1.8.4”
# use new HTTP#post
elsif VERSION == “1.8.3”
# use 1.8.3 #post
else
# use 1.8.2 #post
end

END

You don’t need to call eval, VERSION is a global constant.

On 4/28/06, Jason P. [email protected] wrote:

On 4/28/06, Logan C. [email protected] wrote:

% ruby -e ‘p VERSION’
“1.8.4”

while I guess I could call eval and get that, is there a way to check the
ruby version at runtime? A global var or something?

VERSION

:slight_smile:

while I guess I could call eval and get that, is there a way to check
the
ruby version at runtime? A global var or something?

VERSION

:slight_smile:

no! no! no! no! no! no! no! no! no! no! no! no!

runs screaming down the hall pulling out his hair

of course it is… after glancing at the previous reply, I thought Logan
was
just doing a % ruby -v

such an idiot I am.

:slight_smile:

On Sat, Apr 29, 2006 at 09:07:31AM +0900, Logan C. wrote:

On Apr 28, 2006, at 7:58 PM, Jason P. wrote:

Should I actually check the Ruby version? How would I actually do that?
None of my searches paid off.

Should you? That’s debatable. Could you? Absolutely.

% ruby -e ‘p VERSION’
“1.8.4”

Use RUBY_VERSION to make that future-proof:

$ ruby19 -ve “p VERSION”
ruby 1.9.0 (2006-02-24) [i686-linux]
-e:1: uninitialized constant VERSION (NameError)
$ ruby19 -ve “p RUBY_VERSION”
ruby 1.9.0 (2006-02-24) [i686-linux]
“1.9.0”
$ ruby -ve “p RUBY_VERSION”
ruby 1.8.4 (2005-12-24) [i686-linux]
“1.8.4”

Jason P. wrote:

Should I actually check the Ruby version? How would I actually do that?
None of my searches paid off.

Alternatively, I could catch the ‘NoMethod’ exception, but that would mean
it could potentially take the 1.8.2 code path if I actually goofed a bit in
my 1.8.4 path.

Instead of using the RUBY_VERSION constant, it’s probably better to use
object.respond_to?(:method_name) to determine which version you are
dealing with.

Instead of using the RUBY_VERSION constant, it’s probably better to use
object.respond_to?(:method_name) to determine which version you are
dealing with.


John L.
http://wiseheartdesign.com/

I was considering that, but it seemed like it would be more consistent to
just verify that it runs on each version. Also, it lets me have a nice
clean chunk at the top of the code with a RUBY_VERSION check that
extends
the classes if necessary.