«

On Feb 18, 2004, at 10:14 AM, Dave Thomas wrote:
> The 1.8 branch in CVS has them too.

Hrm. Not the .gz returned by
http://www.ruby-lang.org/cgi-bin/download-1.8.1.mrb, FWIW


> On Feb 18, 2004, at 10:02, Gavin Kistner wrote:
>> While I've got you here...is there a way to get rdoc to document
>> multiple call sequences for a method in a .rb file? I tried mimicking
>> the style seen in time.c:
>
> Not currently. Is that something that would be generally useful?

Mostly, no
However, for times where a method does all sorts of weird type checking
and variable parameters (notably #new methods that have varied call
methods), yes, I think it would.

For example, I have:

# Can be called in one of five ways:
# * <tt>MutableTime.new( )</tt> -- same as #now
# * <tt>MutableTime.new( someString )</tt> -- same as #parse
# * <tt>MutableTime.new( someSeconds )</tt> -- same as #at
# * <tt>MutableTime.new( year, month, ... )</tt> -- same as #local
# * <tt>MutableTime.new( aTimeOrMutableTime )</tt> -- creates a new
MutableTime based off of
# the supplied Time or MutableTime object

def initialize( dateString_Seconds_Time_orYear = nil , *dateTimePieces )



The comments work reasonably well, but to help avoid confusion I feel
the need to create horrific variable names in the actual method itself.
--
(-, /\ \/ / /\/

On Thu, Feb 19, 2004 at 02:23:02AM +0900, Gavin Kistner wrote:
> For example, I have:
>
> # Can be called in one of five ways:
> # * <tt>MutableTime.new( )</tt> -- same as #now
> # * <tt>MutableTime.new( someString )</tt> -- same as #parse
> # * <tt>MutableTime.new( someSeconds )</tt> -- same as #at
> # * <tt>MutableTime.new( year, month, ... )</tt> -- same as #local
> # * <tt>MutableTime.new( aTimeOrMutableTime )</tt> -- creates a new
> MutableTime based off of
> # the supplied Time or MutableTime object
>
> def initialize( dateString_Seconds_Time_orYear = nil , *dateTimePieces )
>

This is commonly solved with several 'constructors'

class << self
def new_from_string(string); ... new(...) end
def new_from_seconds(seconds); ... end
...
end

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Linux: Where Don't We Want To Go Today?
-- Submitted by Pancrazio De Mauro, paraphrasing some well-known sales talk

Gavin Kistner wrote:
> Amazingly, I'm still fighting this. Here's the latest output (using rdoc
> from 1.8.1 on the latest snapshot sources):

For the record, I'm happy to report that getting the latest stable
snapshot, building that, and running the new version of rdoc against
those new sources finally produced the builtins documentation I was
looking for. Yay!

(And as an added bonus, something about the source tree or rdoc
algorithm causes it to process FAR less files, taking <5 minutes, as
opposed to the >20 that it was taking during the failed attempts.)

--
(-, /\ \/ / /\/

On Thursday, February 19, 2004, 7:49:52 AM, Gavin wrote:

> Gavin Kistner wrote:
>> Amazingly, I'm still fighting this. Here's the latest output (using rdoc
>> from 1.8.1 on the latest snapshot sources):

> For the record, I'm happy to report that getting the latest stable
> snapshot, building that, and running the new version of rdoc against
> those new sources finally produced the builtins documentation I was
> looking for. Yay!

> (And as an added bonus, something about the source tree or rdoc
> algorithm causes it to process FAR less files, taking <5 minutes, as
> opposed to the >20 that it was taking during the failed attempts.)

Thanks again, Gavin. That's great news.

Cheers,
er...

>>>>> "D" == Dave Thomas <> writes:

D> I don't know about the rest of your problems, but the above seem to me
D> to be an interpreter problem.

corrected in CVS

Guy Decoux