Forum: Ruby Handling library versions

Hi!

I am trying to implement a library that provides an unified way to
communicate to a server which is changing its API calls from version to
version. I plan to implement it that way:

connect.rb:

class Connect
    def self.getConn(params)
        case params[:version]
            when '4.0' then return Connect4.new(params)
            when '5.0' then return Connect5.new(params)
            else 'Version not supported.'
        end

    end
end

class Connect4
    def initialize(params)
        # Code for v4.
    end
end

class Connect5
    def initialize(params)
        # Code for v5.
    end
end
test.rb:

require 'connect'

conn = Connect.getConn(:version => '4.0')

puts conn

I think it would work, but i'm still new to ruby and there might be
issues i'm not considering. Is there any best practice to handle these
kind of 'challenge'?

Subject: Handling library versions
  Date: Thu 17 Jan 13 03:50:20AM +0900

Quoting Melanie Koller (lists@ruby-forum.com):

>             when '5.0' then return Connect5.new(params)
> end
>
> class Connect5
>     def initialize(params)
>         # Code for v5.
>     end
> end

One of the advantages of object orientation is inheritance - ideal in
your case. I would do something like:

class Connect
  def Connect::get_conn(params)
    case params[:version]
      when '4.0'
        return Connect4::new(params)
      when '5.0'
        return Connect5::new(params)
      end
    end
    raise "Version #{params[:version]} not supported."
  end

  def generic_func
    ..
  end
end

class Connect4 < Connect
  def initialize(params)
    # Code for v4.
  end

  def v4_specific_func
    ..
  end
end

class Connect5 < Connect
  def initialize(params)
    # Code for v5.
  end

  def v5_specific_func
    ..
  end

  def generic_func
    # overloads generic one
  end
end

The advantage is that instances of both Connect4 and Connect5 also
respond to methods defined in Connect. You can thus neatly divide
between things that are unique of each version, and things that are
common among versions.

Carlo

Dear Carlo,

thanks for your answer. I planned to implement it with inheritance. I 
just wanted to keep the Example as simple as possible.

As you don't mentioned anything else i assume there is nothing wrong 
with my approach in general?

Melanie

Subject: Re: Handling library versions
  Date: Thu 17 Jan 13 07:29:24PM +0900

Quoting Melanie Koller (lists@ruby-forum.com):

> As you don't mentioned anything else i assume there is nothing wrong
> with my approach in general?

Ruby has inherited from Perl the aspect of providing many many ways to
obtain the same result. Each person develops his/her
ideosyncrasies. For me, this is very true. For example, I would never
leave out the brackets from the list of parameters of a method (for
matters of readability).

What I can say is that your proposed solution is quite similar to what
I would come up with, but I guess many more options could be
invented. I suggest that, especially at the beginning, you focus on 1)
does it work?, 2) do I have to wait until next week for my results?,
3) do I understand reasonably well what is taking place?, and 4) does
the code look nice? For me, this last element is the most important ;-)

Carlo

hi,

in capistrano they used a hash to map methods for compatibility issues
between versions:
https://github.com/capistrano/capistrano/blob/mast...

i hope it can give you some ideas and good luck
attila