Perché solo un numero limitato di acquisizioni di espressioni regolari è memorizzato in `global_variables`?

Question

Se faccio una partita con un espressione regolare con dieci cattura:

/(o)(t)(th)(f)(fi)(s)(se)(e)(n)(t)/.match("otthffisseent") 

poi, per $10, ottengo:

$10 # => "t" 

ma non è presente global_variables. Ottengo (in una sessione IRB):

[:$;, :$-F, :$@, :$!, :$SAFE, :$~, :$&, :$`, :$', :$+, :$=, :$KCODE, :$-K, :$,, 
:$/, :$-0, :$\, :$_, :$stdin, :$stdout, :$stderr, :$>, :$<, :$., :$FILENAME, 
:$-i, :$*, :$?, :$$, :$:, :$-I, :$LOAD_PATH, :$", :$LOADED_FEATURES, 
:$VERBOSE, :$-v, :$-w, :$-W, :$DEBUG, :$-d, :$0, :$PROGRAM_NAME, :$-p, :$-l, 
:$-a, :$binding, :$1, :$2, :$3, :$4, :$5, :$6, :$7, :$8, :$9] 

Qui, solo i primi nove sono elencati:

$1, :$2, :$3, :$4, :$5, :$6, :$7, :$8, :$9 

Ciò è confermato anche da:

global_variables.include?(:$10) # => false 

Dove è $10 memorizzato, e perché non è memorizzato in global_variables?

Answer 1

Le variabili numerate restituite da Kernel#global_variables saranno sempre le stesse, anche prima che vengano assegnate. Cioè $1 tramite $9 verrà restituito prima ancora che si esegua la corrispondenza e le altre corrispondenze non verranno aggiunte all'elenco. (Possono anche non essere assegnati, per esempio usando $10 = "foo".)

Si consideri il codice sorgente per il metodo:

VALUE 
rb_f_global_variables(void) 
{ 
    VALUE ary = rb_ary_new(); 
    char buf[2]; 
    int i; 

    st_foreach_safe(rb_global_tbl, gvar_i, ary); 
    buf[0] = '$'; 

    for (i = 1; i <= 9; ++i) { 
     buf[1] = (char)(i + '0'); 
     rb_ary_push(ary, ID2SYM(rb_intern2(buf, 2))); 
    } 

    return ary; 
} 

È possibile (dopo abituarsi a guardare C) vedere dal ciclo for che la i simboli $1 tramite $9 sono codificati nel valore restituito del metodo.

Quindi, come è possibile utilizzare ancora $10 se l'output di global_variables non cambia? Bene, l'output potrebbe essere un po 'fuorviante, perché suggerirebbe che i dati della partita fossero memorizzati in variabili separate, ma questi sono solo scorciatoie, delegando l'oggetto MatchData memorizzato in $~.

In sostanza $n visualizza $~[n]. Questo oggetto MatchData (proveniente dalla tabella globale) fa parte dell'output originale del metodo, ma non viene assegnato fino a quando non si esegue una corrispondenza.

Per quanto riguarda la giustificazione per l'inclusione di $1 tramite $9 nell'output della funzione, è necessario chiedere a qualcuno del team principale di Ruby. Potrebbe sembrare arbitrario, ma è probabile che sia stata presa una decisione in merito.

Answer 2

Rubino sembra trattare $1, $2 ecc a livello di parser:

ruby --dump parsetree_with_comment -e '$100' 

uscita:

########################################################### 
## Do NOT use this node dump for any purpose other than ## 
## debug and research. Compatibility is not guaranteed. ## 
########################################################### 

# @ NODE_SCOPE (line: 1) 
# | # new scope 
# | # format: [nd_tbl]: local table, [nd_args]: arguments, [nd_body]: body 
# +- nd_tbl (local table): (empty) 
# +- nd_args (arguments): 
# | (null node) 
# +- nd_body (body): 
#  @ NODE_NTH_REF (line: 1) 
#  | # nth special variable reference 
#  | # format: $[nd_nth] 
#  | # example: $1, $2, .. 
#  +- nd_nth (variable): $100 

BTW, il maximum number of capture groups è 32.767 e si può accedere a tutti via $n:

/#{'()' * 32768}/  #=> RegexpError: too many capture groups are specified 

/#{'()' * 32767}/ =~ '' #=> 0 
defined? $32767   #=> "global-variable" 
$32767     #=> "" 

Answer 3

consideriamo t il suo comportamento come un bug. Lo abbiamo sistemato nel bagagliaio.