[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: [ANN] Non-standard library project
From:       Gavin Sinclair <gsinclair () soyabean ! com ! au>
Date:       2004-06-14 23:19:35
Message-ID: 182-1626442781.20040615091617 () soyabean ! com ! au
[Download RAW message or body]

On Tuesday, June 15, 2004, 1:59:55 AM, James wrote:

> Gavin Sinclair wrote:

>> Hi all,
>> 
>> It's a bit cheeky to call this an announcement, since it's only
>> announcing a project idea.
>> 
>> I would like to create a RubyForge project that builds a library of
>> useful classes and modules.  That basically describes the standard
>> library.  This library wouldn't be standard, hence the name
>> "non-standard library".
>> 
>> The purposes of the project:
>> 
>>  * collect existing small projects (e.g. Memoize) to ensure their
>>    continued maintenance, and hopefully give them higher exposure

> Would these be projects that have reached the end of their development
> (i.e., they're  "done")?

There or thereabouts.

>> 
>>  * provide a good environment for the development of ADTs, etc.
>>    that might otherwise not seem worthwhile due to project
>>    management overhead

> What's ADT?

Abstract Data Type, e.g. binary trees, insert order hashes.

>> 
>>  * provide a rich library that is easy to install and has a high
>>    standard of documentation and testing

> Does rich === large? :)

Yeah, the idea is to be large, just like the standard library.  Also
like the standard library, it's not loaded monolithically.  Thus, for
example:

  require 'nonstdlib'   # LoadError

  require 'nonstdlib/this'
  require 'nonstdlib/that'
  require 'nonstdlib/one_thing'
  require 'nonstdlib/the_other'

>> 
>>    * thus, convenience and quality


> A concern:  n different libraries have ~n owners. How is project 
> access/admin handled through RubyForge?

If a package is added to NSL, it's under the "do whatever you
like with the code" clause of the license, not under the "I am, now
and forever, the maintainer of this code".  Original authors are
welcome to participate, but in practice I suspect many wouldn't bother
and would be happy seeing someone do something with their code (with
credit attributed, of course).  We'll see.  I don't anticipate any
hostile takeovers :)

> Why is this better than having a separate project for each library?  Is
> it that much harder to create a new project than it is to get a project
> added to the NSL?

It's not hard to create a new RubyForge project, but it's a lot of
work.  If someone writes a useful package for their own program and
couldn't be bothered releasing it, it won't see the light of day.
OTOH, it can be included (perhaps with modification, and with some
testing and documentation) in the NSL, then more people are
benefiting.

>> 
>> For example, a very recent thread suggested *replacing* pack and
>> unpack with an OO version (Packer and Unpacker classes).  That's a
>> radical suggestion that's unlikely to be accepted.  The milder
>> approach of providing an OO facade to the existing methods is more
>> reasonable, but if accepted, would still take a long time to appear in
>> a Ruby release.
>> 
>> On the other hand, inclusion of this idea in a 'nonstdlib' project
>> would be feasible and fast.  Before long, you could write in your
>> code something like this:
>> 
>>   require_gem 'nonstdlib', '>= 0.3'

> Another concern (playing Devil's advocate here):  How is this different
> from

>    require_gem 'kitchen_sink_plus_more', '>= 0.3'

You might be implying that such a statement will import *lots* of
stuff into your code, which it wouldn't.  See also my comment about
arbitrary bundling below.

> I think I would prefer to install those libs I expect I'll need, rather
> use bulk packaging.

It's more convenient to install one

> I agree, though, that there is the matter of small, useful libs 
> disappearing over time from owner attrition( I'm finding this to be the
> case with the sysvipc lib), but I'm not convinced about arbitrary bundling.

Well, the bundling will be guided by some (yet to be determined)
principles.  Basically though, if a package *would be* a decent fit
with the Ruby standard library, but the stdlib is not taking offers
right now, then it's good for the NSL.

So there's another false comparison with 'kitchen_sink_plus_more'.
It's not a repository for projects that need a home, despite having
nothing in common.  The aim is to be consistent in purpose, quality,
and presentation, and thus to get more mileage out of the code than
would be likely if the projects were held in isolation.

I'd be interested to know if this addresses your points adequately.

Cheers,
Gavin

PS. Here's a rough list of things I have considered as good candidates
for inclusion (these are ideas, not necessarily existing
implementations):

 * Caching results of method calls (a la Robert Klemme's Memoize)

 * Data types:
   * bounded LRU cache
   * insert order hash

 * some text formatting utils (no specific idea yet)

 * DateTime::Interval

 * Packer/Unpacker classes as recently discussed

Obviously, these are not all well-thought-through proposals for
specific inclusion, just an idea of what sort of things I'm after.

Cheers,
Gavin


[prev in list] [next in list] [prev in thread] [next in thread]