[ruby-core:28497] Re: [Feature #2759] Regexp /g and /G options

2010/3/5 Caleb Clausen <[e-mail]>:
> On 3/4/10, NARUSE, Yui <[e-mail]> wrote:
>> (2010/03/04 14:53), caleb clausen wrote:
>>> It appears there is a patch already.
>>
>> Do you really know how the patch is?
>
> No. Michael referred to a discussion on the japanese ML and said there
> was a patch in it. As I can't understand japanese, I didn't try to
> look into it further. Yusuke Endoh said:
>
>> The reason why Ruby flavor disabled ONIG_OPTION_CAPTURE_GROUP seems:
>>
>> =A0- ONIG_OPTION_CAPTURE_GROUP is not easy to understand (even Kosako sa=
id)
>> =A0- using both named and unnamed capture at the time is considered as b=
ad
>> =A0 =A0and confusing style in Ruby
>> =A0- when it was discussed, there was no compatibility issue because the=
re
>> =A0 =A0was no oniguruma gem
>
> I don't know if he was referring to that specific patch or not. I
> summarized this as:
>
>>> The objections to this feature amounted to "it's complicated for
>>> users to understand and no-one needs it".
>
> Is my summary a mischaracterization? Are there objections to the patch
> beyond those above?

The patch they tought should be the same of my previous patch.
If it is all ok, it should be easy.

But it is not perfetct; those regexp can't be marshalized.
% ./ruby -e'Marshal.load(Marshal.dump(Regexp.new(%q/(a)(?<n>n)\\1\\k<n>/,25=
6)))'
-e:1:in `load': numbered backref/call is not allowed. (use name):
/(a)(?<n>n)\1\k<n>/ (RegexpError)
        from -e:1:in `<main>'

You still think fixing Marshal should be easy.
But in marshal.c:
  case T_REGEXP:
    w_uclass(obj, rb_cRegexp, arg);
    w_byte(TYPE_REGEXP, arg);
    {
      int opts =3D rb_reg_options(obj);
      w_bytes(RREGEXP_SRC_PTR(obj), RREGEXP_SRC_LEN(obj), arg);
      w_byte((char)opts, arg);
    }
You know the value of this option is 256,
but current code marshalize the option as char...
It is difficult to extend this with compatibility.


This is only an example but it shall show the difficulty of
managing complex system.
This is because we are carefull.

--=20
NARUSE, Yui
[e-mail]