[#8478] resolv.rb -- doc patch. — Hugh Sasse <hgs@...>
This is an attempt to get the RD format docs for resolv.rb into
[#8484] strptime fails to properly parse certain inputs — <noreply@...>
Bugs item #5263, was opened at 2006-08-01 23:14
Hi,
Hi,
nobu@ruby-lang.org wrote:
Why bother other languages? They are on their own. We should not
[#8497] Ruby Socket to support SCTP? — Philippe Langlois <philippelanglois@...>
Hi,
[#8504] TCPSocket: bind method missing — hadmut@... (Hadmut Danisch)
Hi,
[#8513] patches for the 1.8.5 deadline... — Hugh Sasse <hgs@...>
As far as I can tell the only patches which I've submitted which
On Aug 3, 2006, at 10:20 AM, Hugh Sasse wrote:
On Fri, 4 Aug 2006, Eric Hodel wrote:
[#8522] IRB change for RDoc workaround — Eric Hodel <drbrain@...7.net>
RDoc chokes on the following code:
[#8525] rdoc bug? — Steven Jenkins <steven.jenkins@...>
I think I've found a bug in rdoc's handling of C files. Specifically, it
[#8555] Process.gid= fails on OS X — <noreply@...>
Bugs item #5351, was opened at 2006-08-08 01:56
>>>>> On Tue, 8 Aug 2006 17:56:07 +0900
Hi,
Hi,
>>>>> On Wed, 9 Aug 2006 12:31:07 +0900
Hi,
[#8561] sandbox timers & block scopes — why the lucky stiff <ruby-core@...>
Two puzzles I am trying to solve:
On 8/8/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/16/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
raise ThisDecayingInquisition, "anyone? anyone at all?"
On Wed, 2006-08-16 at 00:35 +0900, why the lucky stiff wrote:
On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:
On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/15/06, Charles O Nutter <headius@headius.com> wrote:
On Wed, Aug 16, 2006 at 04:14:33AM +0900, Charles O Nutter wrote:
On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
Hi,
[#8568] Pathname.to_a — Marc Haisenko <haisenko@...>
Hi folks,
[#8585] RDoc: extensions spread across multiple C files — Tilman Sauerbeck <tilman@...>
Hi,
Tilman Sauerbeck [2006-08-11 00:39]:
[#8593] ri problem with the latest ruby_1_8 — "Kent Sibilev" <ksruby@...>
Does anyone know why for some strange reason ri doesn't know about any
On Aug 11, 2006, at 10:55 AM, Kent Sibilev wrote:
[#8608] Another ri problem (ruby_1_8 branch) — "Kent Sibilev" <ksruby@...>
I've noticed that many builtin Ruby classes don't have descriptions:
On Aug 12, 2006, at 11:45 PM, Kent Sibilev wrote:
On 8/15/06, Eric Hodel <drbrain@segment7.net> wrote:
[#8609] Again Range=== bug — Ondrej Bilka <neleai@...>
Problem of discrete membership at Range#=== is that it returns unexpected
[#8616] invalid test in "sudo make install-doc"? — <noreply@...>
Bugs item #5415, was opened at 2006-08-14 12:01
[#8662] NODE_WHEN inside a case else body — "Dominik Bathon" <dbatml@...>
Hi,
[#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.
On 8/22/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
On 8/24/06, Dave Howell <groups+2006@howell.seattle.wa.us> wrote:
[#8709] More ri-problems (ruby_1_8 branch again) — Johan Holmberg <holmberg@...>
Hi!
[#8735] Legal operator symbols — "Nikolai Weibull" <now@...>
Why are :>, :>=, :<=, :< fine as symbols, while := isn't?
Hi --
[#8758] sandbox r50, here we go, loading conflicting gems — why the lucky stiff <ruby-core@...>
Checky.
Re: doc patch: weakref.
On Thu, 3 Aug 2006, mathew wrote:
> Hugh Sasse wrote:
> > 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.
> >
>
> I strongly disagree. The purpose of library API documentation is to act as a
> design contract, specifying the behavior of the library call, and not
> specifying anything which the user should not rely on or does not absolutely
> need to know.
>
> Implementation details should not be mentioned in the API, because if they
> are, people will write code that relies on them, and we will then be unable to
> refactor the code later without breaking lots of software.
OK, you've convinced me that this leads to broken encapsulation.
I'll look at this further. It is probably best ensure the contract
is specified by unit tests though, but the creation of a complete
test set has been another topic recently, so I'll say no more here..
Thank you
Hugh