From: "phluid61 (Matthew Kerwin)" <matthew@...>
Date: 2013-04-12T13:23:46+09:00
Subject: [ruby-core:54210] [ruby-trunk - Feature #8110] Regex methods not changing global variables


Issue #8110 has been updated by phluid61 (Matthew Kerwin).


=begin
sam.saffron (Sam Saffron) wrote:
 > Has anyone given any thought at how to make this friendly with older
 > versions of Ruby ... say I have 
 > 
 > def is_foo?(val)
 >   val =~ /foo/
 > end
 > 
 > And now I want this code to work in both 1.9.3 and master. 
 > 
 > # ugly and slow
 > def is_foo?(val)
 >   if defined? Regexp::SKIP_GLOBALS
 >     val =~ /foo/G
 >   else 
 >     val =~ /foo/
 >   end
 > end
 
 [snip]
 
 > # least horribly imho
 > IS_FOO = _G(/foo/)
 > def is_foo?(val)
 >   val =~ IS_FOO
 > end
 > 
 > --- 
 > 
 > So I wonder, is the plan to backport this? Are there any other ways to
 > keep code compatible and clean?

Defining a (({_G})) method in 1.9.* is no more or less a backport than allowing (and possibly ignoring) a /G modifier, and is pretty ugly to boot.  I see no harm in adding some amount of /G support to 1.9.x and 2.0.0, once (if) the functionality is added to trunk, however I also think it is reasonable to expect developers to either
(1) target 2.0.1 by using language features only supported by 2.0.1, or
(2) target <=2.0.0 and 2.0.1 by only using language features that haven't changed, or
(3) go to lengths to explicitly polyfill the older language versions.

Similar things happened with parser changes from 1.8 to 1.9 when adding the new (({{a: 1}})) hash syntax (which makes new code not work in old ruby) and removing the (({if x: y; end})) syntax (which makes old code not work in new ruby).  At least adding a new pattern modifier doesn't break old code.  In fact, it doesn't change the behaviour of the old code at all.

Also note that your "ugly and slow" code won't work because the parser still attempts (and fails) to parse (({/foo/G})) even if the condition is false.

To make your code fully backwards-compatible you'd probably use something like:

 IS_FOO = Regexp.new('foo', defined?(Regexp::SKIP_GLOBALS) ? Regexp::SKIP_GLOBALS : 0)
 def is_foo? val
   val =~ IS_FOO
 end

I also note you've changed /S to /G in your examples.
=end

----------------------------------------
Feature #8110: Regex methods not changing global variables
https://bugs.ruby-lang.org/issues/8110#change-38483

Author: prijutme4ty (Ilya Vorontsov)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor


It is useful to have methods allowing pattern matching without setting global variables. It can be very hard to understand where the problem is when you for example insert a string like `puts pat === my_str` and your program fails in a place which is far-far away from inserted place. This can happen due to replacing global variables of previous pattern match. I caught to this when placed pattern-match inside case-statement and shadowed global vars which were initially filled by match in when-statement.
For now one can extract pattern matching into another method thus defining method-scope for that variables. But sometimes it looks like an overkill. May be simple method like #match_globalsafe can prevent that kind of errors. At least when a programmer see such a method in a list of methods, he's warned that usual match can cause such problems.


-- 
http://bugs.ruby-lang.org/