[ruby-core:33609] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

On Mon, Dec 6, 2010 at 8:48 AM, Urabe Shyouhei <[e-mail]> wrote:
> (2010/12/06 21:17), Charles Oliver Nutter wrote:
>> This is what topic branches are for :)
>
> No.  That idea is not a SVN way.  A trunk in SVN is an actively developed edge
> branch.  In contrast a master branch in Git is a merged collection of topic
> branches, thus they are far less active than SVN trunk.  So in SVN,
> developments goes on the trunk.

My opinion, from dealing with SVN-based projects in the past:

Experimental development should never go on SVN trunk. Trunk should
only contain features that are intended to eventually get into a
release. I'm not sure Refinements qualifies (yet) as an official path
for Ruby, and so it should stay off trunk until that happens.

The alternative would be to let everyone doing any experiment
whatsoever commit to trunk, and then have to sort out what gets into
future releases and what does not. That does not make sense to me.

>> I don't believe refinements
>> should land on trunk, since it's not yet clear whether they should be
>> included at all.
>
> I think it's all what you tell.  You just don't like it, do you?

I like Refinements, once they are "refined" to deal with the issues
brought up in this thread :) I have no objection to them going to MRI
trunk if they have reached the point where they're stable and
acceptable enough to officially be part of Ruby's future.

>> Landing them now, making multiple additional commits
>> to them, and propagating their changes throughout other
>> subsystems...all will make it harder to roll back Refinements if it is
>> decided they shouldn't get into standard Ruby.
>
> You say "now" ... Do you believe it gets easier to roll back as time goes?  I
> don't think so.  If it's a matter of time I can agree with you but...

It gets harder to roll back as time goes on. Maintaining experimental
features on a separate branch until they're blessed to become part of
Ruby's future would ensure they don't have to be reverted much later.

>> I think everyone knows how to check out an alternative branch or
>> repository :) If they would like to assist you (and you would like
>> them to assist you) they can do it that way.
>
> Life is much easier if everyone assisted me testing our ruby_1_8_7 branch
> every day.  Did you know I'm planning a patchlevel release this month?  Have
> you compiled it and run tests?  So far all who actually assisted me was Luis
> Lavena only.
>
> No, I'm not blaming you.  It's all as usual.  Assistance won't happen until
> someone gets some trouble.

If I were more familiar with MRI codebase, I might try to help
"refine" Refinements, but unfortunately the best I can do is explain
my opinions and offer suggestions for improvement here on the list. I
can also try to implement the "refined" portions of Refinements in
JRuby.

As for others who *are* familiar with MRI...I don't see why they'd be
any more likely to assist in "refining" refinements if it were on
trunk versus on a branch. If they're interested in the feature,
they'll contribute wherever it is, no?

>> It shouldn't be done on
>> mainline, in my opinion, until it has solidified a bit more and it's
>> certain to be included in an upcoming "standard" Ruby release.
>
> Define your "a bit more".  Otherwise you can reject a new feature as many time
> as you want with this exact phrase.

A bit more = once Matz says it should go on trunk (ideally, after
other implementers, ruby-core folks, and key community members agree
it's ready to go to trunk).

No offense is intended by either my commentary or my opinions. I just
would like to see Refinements land *after* these issues have been
sorted out. If there's more I can do to help that happen, please let
me know.

- Charlie