Hi,

I admit I haven't paid attention to the libraries as much as I should
have.  Let us discuss "the ideal Ruby bundled library and migration
path to it".

Does somebody take the role of discussion leader?

							matz.

In message "Cleaning up..."
    on 03/04/23, Dave Thomas <dave / thomases.com> writes:

|There an interesting situation developing. As people contribute 
|additional library code to the standard distribution, we end up in the 
|situation where we have a lot of duplication (for example cgi-lib vs. 
|cgi, forwardable vs. delegate, fileutils vs. ftools, Date.strprime vs 
|Time.strptime, getoptlong vs. getopts) and so on. We also have some 
|strange design issues (for example DateTime has the most powerful time 
|parsing routines, but no way of generating a Time object). All this 
|leads to confusion: as a newcomer to Ruby, am I supposed to use ftools 
|or fileutils, for example.
|
|Now, I can see that some folks might argue that this is an historical 
|accident: we need to keep all of these libraries around in order to be 
|compatible with old code. However, that doesn't seem to be a genuine 
|reason. Ruby in reality has very poor compatiblity between major 
|releases: a fair number of the 1.6 code examples in the PickAxe fail 
|under 1.8, and an larger number give warnings. Major changes such as 
|CGI#[] have been made, breaking a whole lot of code.
|
|So, if we're happy to make releases incompatible, perhaps we should use 
|the opportunity to tidy up the libraries as well.
|
|I propose that we create a subdirectory of lib called lib/old, and move 
|all the obsolete library files in to it. This will break some code, but
|
|1. The break is obvious: a compile-time error
|2. The fix is simple: change require 'cgi-lib' to 'old/cgi-lib'
|
|I know that Ruby isn't supposed to be minimal. However, I'm thinking 
|that the current situation is starting to get ugly, and Ruby is not an 
|ugly language.
|
|
|Cheers
|
|
|Dave
|
|  
|     
|
|
|