What are you trying to accomplish?

From a technical standpoint, if you have memory constraints... there are better solutions.

From a maintainability standpoint, you'll have to perform some clever hacks if you want to get access to the hidden lexicals.

If your class is too large for your taste, it probably does too much.

Memory isn't too much of a concern -- although we are running in a mod_perl2 environment, we only have 5 child processes on a 12GB machine.

Startup time isn't too important either (see mod_perl2). Runtime is.

The module represents the business logic layer (the Model) for a web app. Thus it glues together multiple db objects that need to be coordinated for hierarchy and user access, like accounts-to-items, account-to-files relations, etc. So the logical intent is fairly ok (see the POSIX modules as an example of similar grouping).

Much of the verboseness arises from quite a few complex sql queries that are quite long, and for readability reasons, we want to keep them in the file. So the module gets big; around 2000 lines.

Maybe refactoring the class hierarchy is the right thing to do, but there really isn't time to consider that, or move to Moose, at present. Besides, Moose does a lot of the same stuff "under the sheets" with "roles", I'd bet.

I tried the "require" trick, autoloader (shudder), using globals (shudder), Mouse, Filter::Macro, and finally Export with a param list. The last one seems to be a winner; it's only a little bit magical, and its all "real" perl -- all modules pass the perl -cw test. The import and exporter stuff takes up about 20 lines per "split" file but I can write methods there almost exactly as in the main file.

The script

#!/usr/bin/env perl

use strict;
use warnings;

use lib q(./);
use T4;

## Main
#
  my $obj_t = T4->new( name_env => q(foo) );
  print q(>> ) . $obj_t->t_hello_world . qq( <<\n);

  $obj_t->t_set_remote(q(This is a test));
  print q(>> ) . $obj_t->t_get_remote . qq( <<\n);
## END Main
[download]

The Core Module

package T4;

# Pragmas
use strict;
use warnings;
use version; our $VERSION = qv('3.0.0');
use feature qw(:5.10);

# Standard Modules
use Data::Dumper qw(Dumper);
use Class::Std::Utils qw( ident anon_scalar );

my %Attr_Name_Env;
my %Attr_Remote;

use T4::MyMod {
    Href_Attr_Name_Env => \%Attr_Name_Env,
    Href_Attr_Remote   => \%Attr_Remote,
  },
  qw( t_set_remote t_hello_world )
  ;

## Main ##
  ## Constructor 'new'
  #
  sub new {
    ## Get and confirm arguments
    #
    my $class      = shift;
    my $href_arg = {@_};
    my $name_env = $href_arg->{'name_env'};

    ## Bless anon scalar into class
    #
    my $obj_new   = bless anon_scalar(), $class;
    my $idx_self  = ident $obj_new;

    ## Create object attributes
    #
    $Attr_Name_Env{ $idx_self } = $name_env;
    return $obj_new;
  }
  ## END Constructor 'new'

  ## DESTROY
  #
  sub DESTROY {
    my $self      = shift;
    my $idx_self  = ident $self;
    delete $Attr_Name_Env{      $idx_self };
    print STDERR qq(\nDestroyed ) . __PACKAGE__ . qq( object $idx_self
+\n\n);
  }
  ## END DESTROY

  sub t_get_name_env {
    my $self      = shift;
    my $idx_self  = ident $self;
    return $Attr_Name_Env{ $idx_self };
  }

  sub t_get_remote {
    my $self      = shift;
    my $idx_self  = ident $self;
    return $Attr_Remote{ $idx_self };
  }
## End Main ##

1;
[download]

The File with Additional Subs

package T4::MyMod;

use base q(Exporter);
@EXPORT = qw( t_hello_world t_set_remote );

# use Data::Dumper qw(Dumper);

my $Href_Attr_Name_Env;
my $Href_Attr_Remote;

sub import {
  # print STDERR Dumper(@_);

  my $pkg        = shift;
  my $href_attr  = shift;

  $Href_Attr_Name_Env = $href_attr->{Href_Attr_Name_Env};
  $Href_Attr_Remote   = $href_attr->{Href_Attr_Remote};

  T4::MyMod->export_to_level(1, $pkg, @_);
}

  sub t_hello_world {
    my $self      = shift;
    my $idx_self  = ident $self;

    return qq(Hello World $idx_self);
  }

  sub t_set_remote {
    my $self      = shift;
    my $arg       = shift;
    my $idx_self  = ident $self;

    $Href_Attr_Remote->{ $idx_self } = $arg;

    return 1;
  }
1;
[download]

Module::Pluggable, loading the plugins in a BEGIN block, perhaps? If your big module is easily divided into independent pieces, this would probably do the job.

You might look at App::Cmd for an example of this. It lets you build a CLI from a base class plus appropriately-named plugins.

Thank you Pemungkah. I took a look at Pluggable, and it seems interesting. I may return to it if the approach I detailed above doesn't cut it.