Это хорошая практика для экспорта переменных в Perl?

Question

Мне очень удобно передавать конфигурационные и другие данные, которые считываются или рассчитываются один раз, но затем многократно используются в программе с использованием механизма Perl use. Я делаю это, экспортируя хэш в пространство имен вызывающего. Например:

package Myconfiguration;

my %config;

sub import {
    my $callpkg = caller(0);
    my $expsym = $_[1];

    configure() unless %config;

    *{"$callpkg\::$expsym"} = \%config;
}

, а затем в других модулях:

use MyConfiguration (loc_config_sym);

if ( $loc_config_sym{paramater} ) {
    # ... do stuff ...
}

Однако я не уверен в этом как в лучшей практике. Лучше добавить метод, который возвращает хэш-ссылку с данными? Что-то другое?

Answer 1

Если вы хотите только прочитать значения %config, то почему бы не сделать процедуру для вас?

 my %config;
 sub config_value
 {
      my ($value) = @_;
      return $config{$value};
 }

Вы можете экспортировать это по умолчанию, если хотите:

package Mypackage;
require Exporter;
@EXPORT = qw/config_value/;

Причина, по которой я не разрешил бы доступ к хешу повсеместно во многих различных модулях, заключается в том, что мне было бы трудно мысленно отслеживать все места, которые он использовал. Я предпочел бы сделать вышеупомянутую подпрограмму доступа, чтобы, если произошла какая-то ошибка, я мог добавить оператор print к подпрограмме или что-то еще, чтобы узнать, когда происходит доступ к значению. Я не знаю, связано ли это с «лучшими практиками» или это просто потому, что я тупой, но такая путаница, создаваемая глобальными переменными, пугает меня.

Нет причин, по которым у вас не может быть заданной процедуры:

 sub set_value
 {
      my ($key, $value) = @_;
      $config{$key} = $value;
 }

Answer 2

Я предлагаю никогда не экспортировать переменные. Создайте класс, который может вместо этого возвращать ссылку на приватную переменную. Затем люди могут сохранить его в переменной с любым именем и только тогда, когда решат, что хотят его использовать.

Answer 3

Я думаю, что лучше работать с копией хэша конфигурации. Таким образом, если вы измените некоторые элементы, это не повлияет на остальную часть вашего кода.

Обычно я использую простой объект (необязательно Singleton) для этого с одним методом, например get_property().

Answer 4

В общем, лучше разрешить пользователю решать, импортировать символы или нет. Экспортер делает это легко. Написание пользовательского import метода, позволяющего пользователю решать, как назвать импортируемые символы, может быть полезно в редких случаях, но я не думаю, что это один из них.

package MyConfiguration;
require Exporter;

our @ISA       = qw(Exporter);
our @EXPORT_OK = qw(Config);

our %Config;

А потом в вашем скрипте:

use MyConfiguration;
print $MyConfiguration::Config{key};

или

use MyConfiguration qw(Config);
print $Config{key};