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
Should you? That's debatable. Could you? Absolutely.
% ruby -e 'p VERSION'
"1.8.4"
···
On Apr 28, 2006, at 7:58 PM, Jason Persampieri wrote:
Should I actually check the Ruby version? How would I actually do that?
None of my searches paid off.
Jason Persampieri 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.
···
--
John Long
http://wiseheartdesign.com/
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 
_jason
···
On 4/28/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
On Apr 28, 2006, at 7:58 PM, Jason Persampieri wrote:
> Should I 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"
···
On Sat, Apr 29, 2006 at 09:07:31AM +0900, Logan Capaldo wrote:
On Apr 28, 2006, at 7:58 PM, Jason Persampieri 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"
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
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 Long
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.
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 Apr 28, 2006, at 8:22 PM, Jason Persampieri wrote:
On 4/28/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
On Apr 28, 2006, at 7:58 PM, Jason Persampieri wrote:
> Should I 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"
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 
_jason
> 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

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.
