[#927] UnboundMethod#to_proc — Dave Thomas <dave@...>
I'm wondering what I can do with a Proc generated by
17 messages
2003/04/06
[#929] Re: UnboundMethod#to_proc
— "Chris Pine" <nemo@...>
2003/04/06
----- Original Message -----
[#934] Re: UnboundMethod#to_proc
— Mathieu Bouchard <matju@...>
2003/04/06
[#940] Re: UnboundMethod#to_proc
— chr_news@...
2003/04/07
>
[#941] Re: UnboundMethod#to_proc
— Dave Thomas <dave@...>
2003/04/07
>> If they have diverging interfaces such that the contracts conflict
[#936] docs on implementation of ruby and/or ruby-gc ? — Ruben Vandeginste <Ruben.Vandeginste@...>
4 messages
2003/04/07
[#964] Range in logical context — Dave Thomas <dave@...>
If I run
7 messages
2003/04/16
[#965] Re: Range in logical context
— Mauricio Fern疣dez <batsman.geo@...>
2003/04/16
On Thu, Apr 17, 2003 at 06:10:40AM +0900, Dave Thomas wrote:
[#973] problem with rb_rescue2() ? — Mathieu Bouchard <matju@...>
5 messages
2003/04/19
Re: Cleaning up...
From:
matz@... (Yukihiro Matsumoto)
Date:
2003-04-28 07:24:55 UTC
List:
ruby-core #993
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
|
|
|
|
|
|