¿Cómo se implementan los modificadores de acceso a funciones y variables en Perl? ¿Por qué el lenguaje no tiene un sistema de public/private/protected como otros lenguajes de programación, y cómo se limita el acceso a los datos internos de los módulos en Perl?

Respuesta.

En Perl no existe un sistema clásico de modificadores de acceso como public/private/protected. Todo el control de acceso a funciones y datos se realiza a través de convenciones y el alcance de las variables.

• Para restringir el acceso a variables en un módulo se utiliza la palabra clave my (alcance léxico dentro del archivo o bloque) y la exportación de símbolos (a través de Exporter o mecanismos propios).
• Las subprogramas no exportadas (@EXPORT, @EXPORT_OK) permanecen por defecto "internas" para el módulo, aunque siempre se pueden llamar explícitamente con el prefijo del paquete si se desea.
• Se acostumbra a empezar las funciones y variables internas con un símbolo de subrayado (_internal_sub), lo que sirve como una convención de privacidad.

Ejemplo:

package MyLib;
use Exporter 'import';
our @EXPORT_OK = qw(public_func);

my $secret = 123; # No accesible desde fuera

sub public_func {
    _internal_func();
}

sub _internal_func {
    print "¡Esto es interno!
";
}

1;

Pregunta capciosa.

¿Qué medidas protegen a la función privada del módulo Perl contra llamadas externas? ¿No se puede llamar directamente?

Respuesta: De hecho, se pueden llamar explícitamente cualquier subprograma del paquete con el nombre completo: MyLib::_internal_func(). Perl no restringe técnicamente esta llamada; la protección está solo a nivel de convención.

Ejemplos de errores reales por desconocer los matices del tema.

---

Historia

Un desarrollador exportó demasiadas funciones del módulo, olvidando la restricción a través de @EXPORT_OK. Como resultado, los usuarios accidentalmente accedieron a funciones internas, lo que llevó a conflictos de nombres y un uso incorrecto de la API.

---

Historia

En un gran proyecto, dos equipos utilizaron el mismo método interno (que comienza con _), pensando que era privado. Más tarde cambiaron la interfaz de la función, lo que rompió las llamadas desde otra parte del sistema.

---

Historia

En uno de los proyectos, se modificó un módulo de un desarrollador externo, llamando directamente a sus métodos no exportados. Después de actualizar la distribución, el módulo dejó de funcionar, ya que los nombres internos de las funciones habían cambiado, lo que provocó la caída de la aplicación.