in reply to Re^2: __DATA__ used in BEGIN
in thread __DATA__ used in BEGIN

For these objects , hashes were created, as a kind of exception to the rule and these were initialized at the loading the module.

...

To be short, a (huge) hash has to be initialised at run time.

This is still confusing. Are you sure you need to do this in a BEGIN block? If you really need to initialize this hash "at runtime" as you say, then you can do it in normal code. (And if you can do it in normal code, I would suggest calling a sub that returns the hash, rather than using __DATA__.)

Also unclear is whether this initialization is happening in a script or in a module. If it's a module and you just need the hash to be created when the module is used, then again a BEGIN block is not necessary. If, on the other hand, it's in a script and you need the hash to be created before any modules are loaded, then BEGIN is necessary.

It would help to see some actual code here.

Replies are listed 'Best First'.
Re^4: __DATA__ used in BEGIN
by Tabari (Monk) on Nov 12, 2007 at 17:05 UTC
    Part of the messy structure is of course due to the fact that it is a cleanup.
    The initialisation of the hash was done in the BEGIN section, I wanted to preserve the original structure, but apart from that, there is no real need and it can indeed be replaced by a subroutine call.
    Difficult to say where such a cleaning effort should stop and hints on that would be most welcome too.
    This is part of my BEGIN section, I left out part of the here document, as it is not instructive, but it is of course the source of the big hash: 
    



#
# Intiliase global data and hint settings
# 
BEGIN
{
    %database_platforms = (
               "ora"    => "Oracle",
               "sql"    => "Sybase",
               "mss"    => "Mssql"
              );
    my %hints_setting = (
             "MODULE"   => \&set_object_module_hint,
             "TYPE"     => \&set_object_type_hint,
             "TEMPLATE" => \&set_object_template_hint
    );
    my $hints =  <<HINTS_DATA;
TYPE:unknown:f_ali_alb_init_profile.mss:procedure 
TYPE:unknown:f_ali_alb_init_profile.ora:procedure 
MODULE:unknown:v_state_dr.ora:misc   
HINTS_DATA
      
    my @hints = split /\n/, $hints;                    
                      
    foreach (@hints) {
             chomp;
             my @line = split /:/;
             my $proc = $hints_setting{ shift @line };
             &{$proc}( @line ) if ($proc);
    }
    
    $history_delimitertext = "--DO NOT CHANGE BELOW THIS LINE--LASTLOG
+=";
}

    [download]
    The (already exisitng) module set_object_module_hint goes as follows: 
    sub set_object_module_hint
{
    my ($project)    = $_[0];
    my ($objectname)    = $_[1];
    my ($modulename)    = lc ($_[2]);
    $modulename     =~s/\s//g;     
    my ($result);

    $result = 0;
    if ($modulename eq "misc") {

        if (exists $object_module_hints {$objectname}) {
            log_message "Overriding module hint '$modulename' for data
+base object name '$objectname'";
        }
        $object_module_hints {$objectname} = $modulename;
        $result = 1;

    } else {
      log_error "Invalid module hint '$modulename' for database object
+ name '$objectname'";
    }
    return $result;
}

    [download]
    The global variable is used in some places, but not too many, so I am inclined to follow your suggestion.

    Tabari
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom