[#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: Dave Thomas <dave@...>
Date: 2004-02-12 16:54:11 UTC
List: ruby-core #2412
On Feb 12, 2004, at 10:19, Sean E. Russell wrote:

>> Method documentation is neccesary to help people understand the code -
>> I agree.  Without type information it can be hard to understand a
>> method at a glance.
>
> Sorry, I wasn't being clear.  I was trying to say that Hiroshi doesn't 
> like
> code duplication, but there is no way to avoid the kind of duplication 
> he's
> complaining about because there's no other way to extract that 
> information
> automatically.

Quite often though you can get away with some common sense parameter 
naming.

    # Iterate over the contents of the AddressBook
    def each_person
       . . .
       yield name, address_book_entry
      . . .
    end

If you RDoc'd that, you'd get


     ------------------------------------------------
     each_person() {|name, address_book_entry| ...}
     -------------------------------------------------
     Iterate over the contents of the AddressBook

Which is probably good enough. I don't think you'd need to add extra 
comments to say that "address_book_entry" is an instancfe of an 
AddressBook..

> I remember having a discussion with Dave about the possibility of 
> having rdoc
> extract constraints from the documentation and generating or running 
> them in
> the form of unit tests.  Dave, I'm a bit out of touch with what you're 
> up to
> these days; have you given this any more thought?
>

I was concerned about the security issues of this, and to be frank 
right now I don't have the time to dig deeper in to it. If someone 
wants to come up with a proposal, and eventually some code, I'm game... 
:)

> Also, since I'm a lazy cuss, does anybody know what the consequenses 
> of having
> Ruby source files that consist of enormous amounts of comments is?

FWIW, I think we need to resist the temptation to add too much 
documentation to the files. I agree with Gavin: a section at the top 
explaining intent and usage, and enough information on each public 
method and class to get someone started. Many public methods get a 
single line comment, some get a lot more.


Cheers

Dave


In This Thread