From: David Alan Black Date: 2002-01-13T09:10:11+09:00 Subject: Re: RCRCR Hello -- On Sun, 13 Jan 2002, Matt Armstrong wrote: > David Alan Black writes: > > > Hello -- > > > > Yes, a Ruby Change Request Change Request. > > > > It seems to me that RCRs fall into several categories, and that those > > categories are different enough from each other that it would be worth > > turning them into different things. The RCR label, in my view, is > > flattening things out to much; there's a big difference, say, between > > wanting #lstrip added to String and wanting method overloading based > > on number of arguments. > > What is the practical problem with the current system? Is the RCR > list getting too large? Do you want to be able to sort/search based > on the new criteria? Do you want to prioritize RCRs with these new > categories? > > I'm not necessarily against further categorization, but the benefit is > not obvious to me. I do think there are too many RCRs, though that isn't my main focus here. The reason I think categories or tags would be nice is that what we're now calling "RCR"s actually have very little in common with each other. Also, in more practical terms, the "enhancement" requests might feed directly into the kind of snippet libraries that have been talked about here recently. Putting code-breaking or deeply language-affecting stuff into such libraries is a completely different matter (as I can tell you from having worked on Ruby Behaviors :-) So a more affirmative way to put it might be that denoting the "enhancement" RCRs in some way would isolate them for implementation and distribution. I've always thought that one of the big merits of the various flavors of snippet collecting we've talked about would be to take the pressure off the RCR process. > > Ruby Alteration Request > > Ruby Enhancement Request > > Ruby Optimization Request > > I think that if anything, these should just be a "category" field in a > particular RCR. I.e. a given RCR can be an alteration, enhancement, > optimization, etc. That's pretty much a cosmetic matter, as long as the designation is retrievable. > The problem with ditching RCR in favor of more top level categories is > that joe user who files his idea into the system may not even know if > his idea is an enhancement or an alteration, etc. The main issue is whether a proposed change would, or could, break existing code. If it's purely additive, then it can't; if it changes a method's interface, then it can. I have to add, perhaps at the risk of sounding, I don't know, slightly high-handed, that I fairly strongly feel that anyone who can't make this determination probably shouldn't be asking for changes to the core language. David -- David Alan Black home: dblack@candle.superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav