• Publicidad

Rendimiento y código claro en módulo con funciones

¿Ya sabes lo que es una referencia? Has progresado, el nível básico es cosa del pasado y ahora estás listo para el siguiente nivel.

Rendimiento y código claro en módulo con funciones

Notapor Kamikaze » 2015-11-17 13:08 @589

Hola.

Estoy creando el típico módulo con una serie de funciones que luego se usarán en otro script. Y tras leer documentación, entiendo que lo mejor es exportar esas funciones, y aquí es donde me aparecen las dudas:

Cuando se usan en el script esas funciones del módulo, se las llama simplemente con el nombre:
Sintáxis: [ Descargar ] [ Ocultar ]
Using perl Syntax Highlighting
  1. use strict;
  2. use warnings;
  3. ...
  4. use Mimodulo.pm; # donde está definida la función f_leerTabla(), y que se exporta
  5. ...
  6. # Código del script
  7. ...
  8. f_leerTabla($tabla,$reg); # llamada a función de Mimodulo.pm
  9. ...
  10.  
Coloreado en 0.002 segundos, usando GeSHi 1.0.8.4

Pero a medida que el código va haciéndose más grande y se necesitan llamadas a distintas funciones de distintos módulos, al usar la llamada a función como en el ejemplo de arriba, a la largo llevará a problemas de compresión.

Por eso sé que se pueden llamar a las funciones de los distintos módulos, sin necesidad de exportar esas funciones usando:
Sintáxis: [ Descargar ] [ Ocultar ]
Using perl Syntax Highlighting
  1. ...
  2. Mimodulo::f_leerTabla($tabla,$reg);
  3. ...
  4.  
Coloreado en 0.001 segundos, usando GeSHi 1.0.8.4

De esta forma está mucho más claro saber dónde está la función usada.

Y las preguntas serían:

1- ¿Se pierde rendimiento al no exportar esas funciones del módulo?
2- Si se exportan esas funciones, y se usa la llamada usando el separar "::", ¿es una redundancia que no sirve para nada?

Un saludo.
Kamikaze
Perlero nuevo
Perlero nuevo
 
Mensajes: 6
Registrado: 2009-07-21 09:59 @458

Publicidad

Re: Rendimiento y código claro en módulo con funciones

Notapor explorer » 2015-11-17 17:41 @778

No puedo darte detalles exactos, porque los desconozco, pero lo que hace Perl y el módulo Exporter es agregar los nombres de los subrutinas de tu módulo al espacio de nombres principal, para que parezcan que están declaradas ahí, y de esa forma, no ser necesarios poner el nombre completo (abreviar a la hora de escribir código).

No entiendo qué problema puede haber al crecer el programa. Lo que hay que tener es una política clara de la nomenclatura a usar a lo largo de toda la aplicación, para que cada subrutina, con su nombre, indique claramente qué hace, y en algunas ocasiones, a qué se refiere.

Por ejemplo, podemos tener dos módulos que tengan dos subrutinas que se llamen pintar(). Cada una de ellas pinta cosas distintas (una puede pintar una tabla y la otra pintar los argumentos pasados al programa, por ejemplo). Está claro que no podemos importarlas al mismo código porque tienen el mismo nombre.

La solución es darles nombres más declarativos. A una le llamaremos pintarTabla() y a la otra pintarArgumentos(). Asunto resuelto.

O... nos pasamos a la POO:
Sintáxis: [ Descargar ] [ Ocultar ]
Using perl Syntax Highlighting
  1. my $argvs = Args::new(@ARGV);
  2. my $tabla = Tabla::new();
  3. ...;
  4. $tabla->pintar();
  5. $argvs->pintar();
Coloreado en 0.001 segundos, usando GeSHi 1.0.8.4

Aquí no hay duda: depende de la clase del objeto, su pintar() será distinto.

En respuesta a tus preguntas, creo que son 'no', y 'sí'. Bueno, un 'si' junto con 'por que Perl te lo permite hacer, así que es decisión tuya' :)
JF^D Perl programming & Raku programming. Grupo en Telegram: https://t.me/Perl_ES
Avatar de Usuario
explorer
Administrador
Administrador
 
Mensajes: 14486
Registrado: 2005-07-24 18:12 @800
Ubicación: Valladolid, España

Re: Rendimiento y código claro en módulo con funciones

Notapor Kamikaze » 2015-11-18 13:38 @610

Hola.

Está claro que una base correcta en la nomenclatura es primordial, y es algo que siempre sigo ;) Pero no está de más haberlo comentado ;)

Básicamente todo iba para explicar las dos preguntas que hice al final, y que con tus respuestas ya me queda claro con qué sentido es la idea de exportar, además de los beneficios que tiene un módulo. Así que lo mejor es seguir exportando que para eso está implementada esa opción.

El consejo de usar clases, donde sin duda ya quedaría mucho más claro, en mi caso particular no son necesarias... por ahora. Quién sabe si más adelante tendré que usarlas, pero eso ya es otro cantar.

Pues nada, gracias por despejarme las dudas de si exportar o no.

Un saludo.
Kamikaze
Perlero nuevo
Perlero nuevo
 
Mensajes: 6
Registrado: 2009-07-21 09:59 @458


Volver a Intermedio

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados

cron