[#8484] strptime fails to properly parse certain inputs — <noreply@...>

Bugs item #5263, was opened at 2006-08-01 23:14

13 messages 2006/08/02
[#8485] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — Yukihiro Matsumoto <matz@...> 2006/08/02

Hi,

[#8538] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — nobu@... 2006/08/06

Hi,

[#8561] sandbox timers & block scopes — why the lucky stiff <ruby-core@...>

Two puzzles I am trying to solve:

28 messages 2006/08/08
[#8624] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

raise ThisDecayingInquisition, "anyone? anyone at all?"

[#8627] Re: sandbox timers & block scopes — MenTaLguY <mental@...> 2006/08/15

On Wed, 2006-08-16 at 00:35 +0900, why the lucky stiff wrote:

[#8628] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:

[#8629] Re: sandbox timers & block scopes — "Charles O Nutter" <headius@...> 2006/08/15

On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:

[#8690] a ruby-core primer — why the lucky stiff <ruby-core@...>

Hello, all. I've been working on the ruby-core page for the new Ruby site.

21 messages 2006/08/22

Re: doc patch: weakref.

From: Hugh Sasse <hgs@...>
Date: 2006-08-02 09:53:50 UTC
List: ruby-core #8487
On Wed, 2 Aug 2006, Eric Hodel wrote:

> On Aug 1, 2006, at 2:13 AM, Hugh Sasse wrote:
> > On Tue, 1 Aug 2006, Eric Hodel wrote:
> > > On Jul 31, 2006, at 3:20 AM, Hugh Sasse wrote:
> > > 
> > > > When this happens #weakref_alive? will return false.
> > > 
> > > I think this part of the description should be added to #weakref_alive?
> > 
> > I just thought something in the introductory text would provide context
> > for reading the other methods.
> 
> It also ends up being documented twice.

OK, violation of DRY in comments is probably as bad as code for maintennce.
I'll concede this.
> 
> > > > Because Weakref inherits from Delegator it passes method calls to the
> > > > object
> > > > from which it was constructed, so it is of the same Duck Type.
> > > 
> > > How about something like:
> > > 
> > > A Weakref delegates calls to the referenced object so it can be used in
> > > place of the real object.
> > 
> > My text explains the use of the constructor, helps support the docs
> > of Delegator (as a concrete example) and explains that it works because
> > of Duck Typing rather than anything else.
> > I feel your text leaves some of this unsaid.  But it would suffice
> 
> It is also an implementation detail.  I'd rather explain how it works than how
> it is implemented.  They can read the code to determine the implementation.

Not sure that's such a problem: the interface is unlikely to change
once established, and helping people understand how parts of the 
standard library work is the point of docs.  But I don't feel strongly 
about this.  It could be argued this violates DRY also, though.
> 
> > > > +  # Determine if this Weakref still refers to anything.
> > > >  def weakref_alive?
> > > >    @@id_rev_map[self.__id__] == @__id
> > > >  end
> > > 
> > > How about:
> > > 
> > > Returns false if the referenced object has been garbage collected.
> > 
> > It's a method ending in ? so we know it is a boolean. You text has
> > an implicit not in there i.e. "returns false if [...] garbage collected,
> > [returns true if it has not]"  which I think is less clear, because
> > it is the opposite sense to what the method name says.
> 
> I feel my description makes it most clear which states return which result.

OK, what about:

   # Returns true if the referenced object still exists, and
   # false if it has been garbage collected.

then?   
> 
        Hugh

In This Thread