[#2367] Standard libraries — Dave Thomas <dave@...>

From ruby-dev summary:

60 messages 2004/02/11

[#2397] PATCH: deprecate cgi-lib, getopts, importenv, parsearg from standard library — Gavin Sinclair <gsinclair@...>

Index: cgi-lib.rb

15 messages 2004/02/12

[#2465] PATCH: OpenStruct#initialize to yield self — Gavin Sinclair <gsinclair@...>

This is a common approach I use to object initialization; I don't know

24 messages 2004/02/19

Re: Standard libraries

From: "Gavin Sinclair" <gsinclair@...>
Date: 2004-02-12 02:56:13 UTC
List: ruby-core #2377
> |Sounds good.  Is there sense in starting a discussion about removing
> |some out-of-date libraries now?
>
> Yes.

OK, what about 'cgi-lib', 'getopts', 'importenv', and 'parsearg'?  Here
are some options (for example, with 'getopts'):

 * remove lib/getopts.rb

 * replace the contents of lib/getopts.rb with
     raise "'getopts' is no longer supported from 1.8.2 onwards"

 * add a deprecation warning, but let the code work anyway, and
   remove it after 1.8.2 (or whenever is suitable)

 * move lib/getopts.rb to lib/_old/getopts.rb, forcing users to change
   code

 * as above, but make lib/getopts.rb look like this:

     warn "getopts.rb is deprecated and will disappear after 1.8.2"
     require 'lib/_getopts'

I'm not sure what's the best option.  I imagine that practically no code
is written for Ruby 1.8 that uses libraries like these, so I'd be inclined
to just remove them!

If we wish to deprecate (which is wise, I suppose), then I like the idea
of an _old directory.  It puts all the unwanted code in one place and
removes it from the lib directory.

What are your thoughts, Matz?  I'll happily create a patch for any
scenario you wish in order to clean these files up.


> |Also: base64.  Can we put the recent HEAD change (modularisation, and
> |deprecating the top-level namespace pollution) in the 1.8 branch as
> |well?  It makes sense to deprecate it now, IMO.
>
> OK.  Could you put it to 1.8?

Can do (tonight, Japanese time).

Gavin



In This Thread