[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>

Okay. I've got Ruby compiling. I'm attempting to get everything in

17 messages 2006/01/05
[#7058] Re: More on VC++ 2005 — nobuyoshi nakada <nobuyoshi.nakada@...> 2006/01/06

Hi,

[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)

Hi,

22 messages 2006/01/10
[#7097] Re: mathn: ugly warnings — Daniel Berger <Daniel.Berger@...> 2006/01/10

Hadmut Danisch wrote:

[#7098] Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/10

Daniel Berger wrote:

[#7118] Re: Design contracts and refactoring (was Re: mathn: ugly warnings) — mathew <meta@...> 2006/01/12

*Dean Wampler *<deanwampler gmail.com> writes:

[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>

Hello,

23 messages 2006/01/28
[#7228] Re: Question about massive API changes — Caleb Tennis <caleb@...> 2006/01/28

>

Re: Question about massive API changes

From: mathew <meta@...>
Date: 2006-01-29 20:42:38 UTC
List: ruby-core #7241
Wilson Bilkovich wrote:
> My opinion is rather extreme: if Ruby is already at a point where
> something in the stdlib can't be improved without a fork, it might be
> time to start shopping for a new language.
>   

This is exactly the issue I was trying to discuss in the thread about 
the importance of API documentation. There are already bits of stdlib 
that basically can't be touched, like the rss parser.

I think the Ruby 2.0 "breakage point" is a good opportunity to have a 
policy that only code that can be refactored without breakage (i.e. code 
with a documented API) should be included in the standard library.

> If you're familiar with Java, you'll know how crazy it is to browse
> the standard library.  Partly this is because things marked for
> deprecation in version 1.1 are still in there, happily working a
> decade later.
>   
That, and nobody thinks about what would be the right API before going 
away and building the code. It's "Java needs something to do X, this is 
something to do X, therefore shove it in the standard library"--even if 
there's no documentation, the API is a mess, it's non-reentrant code, or 
whatever.


mathew

In This Thread