Lo bueno, lo malo y lo feo de $ léxica _ en Perl 5.10+

Question

A partir de Perl 5.10, ahora es posible alcance léxico la variable de contexto $_, ya sea explícitamente como my $_; o en una construcción de given / when.

¿Ha encontrado a nadie usos buenas de la $_ léxica? ¿Hay alguna construcciones más simple / seguro / más rápido?

¿Qué hay de las situaciones que tiene más complicado? Ha introducido el léxico $_ cualquier error en su código? (Ya que las estructuras de control que escribir a $_ usarán la versión léxica si es en su alcance, esto puede cambiar el comportamiento del código si contiene llamadas a subrutinas (debido a la pérdida de margen dinámico))

Al final, me gustaría construir una lista que aclara cuándo utilizar $_ como un léxico, como global, o cuando no tiene ninguna importancia.

---

NB: como de perl5-5.24 estas características experimentales son ya no forma parte de Perl .

Answer 1

OMI, una gran cosa para salir de $_ léxico es el nuevo símbolo prototipo _.

Esto le permite especificar una subrutina de modo que se tardará un escalar o si no se proporciona ninguno se agarra $_.

Así que en lugar de escribir:

sub foo {
    my $arg = @_ ? shift : $_;

    # Do stuff with $_
}

Puedo escribir:

sub foo(_) {
    my $arg = shift;

    # Do stuff with $_ or first arg.
}

No es un gran cambio, pero es sólo que mucho más simple cuando quiero que el comportamiento. la eliminación repetitivo es una cosa buena.

Por supuesto, esto tiene el golpe de efecto de cambiar los prototipos de varios órdenes internas (por ejemplo chr), que puede romper algo de código.

En general, celebro $_ léxico. Me da una herramienta que puede utilizar para limitar munging accidental de datos y las interacciones entre las funciones extrañas. Si decido usar $_ en el cuerpo de una función, por lexicalizing, puedo estar seguro de que todo lo que el código de llamada, $_ no se modificará en el código de llamada.

dinámico ámbito de aplicación es interesante, pero en su mayor parte Quiero ámbito léxico. Añádase a esto las complicaciones de todo $_. He oído advertencias sobre la inconveniencia de hacer simplemente local $_; - que lo mejor es utilizar for ( $foo ) { } lugar. $_ lexicalized me da lo que quiero 99 de cada 100 veces cuando he localizado $_ por cualquier medio. $_ léxica hace una gran comodidad y facilidad de lectura característica más robusto.

La mayor parte de mi trabajo ha tenido que trabajar con Perl 5.8, así que no he tenido el placer de jugar con $_ léxico en proyectos de mayor envergadura. Sin embargo, parece que este va a recorrer un largo camino para hacer que el uso de $_ más seguro, que es una cosa buena.

Answer 2

He encontrado una vez que un tema (bug sería demasiado fuerte de una palabra) que le ocurrió cuando estaba jugando un poco con el Inline módulo. Este sencillo script:

use strict qw(vars subs);
for ('function') {
    $_->();
}
sub function {
  require Inline;
  Inline->bind(C => <<'__CODE__');
void foo() 
{
}
__CODE__
}

falla con un mensaje de error Modification of a read-only value attempted at /usr/lib/perl5/site_perl/5.10/Inline/C.pm line 380.. En las profundidades de las partes internas del módulo Inline es una subrutina que quería modificar $_, lo que lleva al mensaje de error anterior.

Uso

for my $_ ('function') { ...

o de lo contrario se declara my $_ es una solución viable a este problema.

(El módulo Inline fue parcheado para solucionar este problema particular).

Answer 3

[ Justificación: Una respuesta adicional a corto con un breve resumen para los recién llegados Perl que pueden ser de paso. Durante la búsqueda de "tema léxica Perl" uno puede terminar aquí.]

A estas alturas (2015) que supongo que es de conocimiento común que la introducción del tema léxica (my $_ y algunas características relacionadas) llevado a algunos difícil de detectar en los comportamientos principio no deseados y así fue marcado como experimental y luego entró en una desaprobación etapa .

---

  

Resumen parcial de #RT119315 :    Una de ellas fue por algo así como use feature 'lextopic'; a hacer uso de un nuevo   léxica variables tema:    $^_ .    Otro punto que se hizo fue que un "nombre implícita para el operador topicalizing ... aparte de $_ " que funciona mejor cuando se combina con funciones de forma explícita léxicas ( por ejemplo, léxica map o lmap). Si estos enfoques podrían de alguna manera hacen posible given/when de rescate no está claro. En el más allá de las fases experimentales y tal vez algo de depreciación puede terminar viviendo en en el río de CPAN.   

Answer 4

no han tenido ningún problema aquí, aunque tienden a seguir un poco de una política de "no preguntar, no decir" cuando se trata de magia Perls. Es decir. las rutinas no son general se espera que confiar en sus pares de atornillado con datos no léxicas como un efecto secundario, ni dejar que ellos.

He probado código contra diversas 5.8 y 5.10 versiones de Perl, mientras se utiliza un 5,6 describir Camel para la referencia ocasional. No he tenido ningún problema. La mayor parte de mis cosas fue hecho originalmente para el Perl 5.8.8.