Hello --

On Sun, 13 Jan 2002, Matt Armstrong wrote:

> David Alan Black <dblack / candle.superlink.net> 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