From: Robert Klemme <shortcutter@...>
Date: 2010-11-14T18:30:14+09:00
Subject: Re: Ruby class versioning

On 14.11.2010 00:02, Tim D. wrote:
> Today I've started investigating this ruby/rails thing. Love the
> concept. Worked for many years in java projects and am constantly
> frustrated by the number of times i configure the same old frameworks
> and components.

Java certainly looks a lot more engineered compared to Ruby.  If that 
haunts you in the Java world you will feel a lot more at home here. 
OTOH complex systems are - well - complex.  So if you build the same 
thing in Ruby it will have similar complexity.  Although some things are 
significantly less verbose in Ruby because of the dynamic nature and 
absence of static typing.

> A concern I have with java which i'd hoped Ruby would solve is class
> versioning. In java we're often confronted by cryptic errors due to
> conflicts in the versions of required libraries. Spring-1.0.0 needs
> commons-1.0.0 but hibernate-1.2.2 wants commons-1.1.0. You select
> commons-1.1.0 because it's the best option you have but the new version
> breaks an interface contract in some minor way and suddenly you've lost
> a week of work!
>
> Does Ruby have a mechanism for avoiding this?

Not directly but please note that because of Duck Typing (and hence lack 
of interfaces) the issue is less dramatic in Ruby.  And since many Gems 
are Ruby only you even have the option to fix them yourself.

Judging from this forum's history the issue you are bringing up does not 
seem to be prevalent.  I suggest you put your worries aside for the 
moment, try it out and see how it goes. :-)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/