Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

best practice: where to put constants

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


jarom at jaromsmith

Jun 4, 2009, 8:20 AM

Post #1 of 14 (1430 views)
Permalink
best practice: where to put constants

Hi all:

This is probably my lack of Perl knowledge showing... but where would be
the best-practice place to put constants in my code? I'm talking about
magic numbers that I use internally but need to reference in multiple
locations of the code. Things like

"VENDOR_COMMIT" => 1,
"VENDOR_DECLINE" => 2,
"TIME_OUTSIDE_WINDOW" => 3,

In Java I would declare them as "public static final" members the class
that describes that particular object (in this case, a vendor
notification) and I would refer to them like

if (notification.getAction() == Notification.VENDOR_COMMIT) ....

So I think the analog to that in Catalyst would be to define the
constant(s) in the ResultSource classes that are automatically generated
for me (below the line) and then refer to them like

if ($notification->action ==
MyApp::Schema::ResultSet::Notification::VENDOR_COMMIT) ....

The problem with doing it that way is that the namespace starts to
become unwieldly, and I have to remember where I put the thing I'm
trying to reference. The alternative would be to put them at the top
level, i.e., in MyApp.pm:

use constant NOTIFICATION_VENDOR_COMMIT => 1;
use constant NOTIFICATION_VENDOR_DECLINE => 2;
use constant NOTIFICATION_TIME_OUTSIDE_WINDOW => 3;

use constant NOTIFICATION_PROPERTY_ACCEPT => 1;
use constant NOTIFICATION_PROPERTY_CANCEL => 2;
use constant NOTIFICATION_PROPERTY_OFFER_NEW_WINDOW => 3;

and then in the code I just say

if ($notification->action == MyApp::VENDOR_COMMIT) ....

In the end, this is what I decided to do because I have relatively few
of these guys (so far) and I'd rather have them thrown together all in
one place than spread all over the system. But I'm wondering if there
is a best practice?

I don't want to put them in the config hash or in a configuration file
because these are not things that a user should be able to change or
override.

Thanks in advance for the advice/insight; this group has been a great
help so far.

jarom smith
tech go-to guy



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Jun 4, 2009, 8:31 AM

Post #2 of 14 (1361 views)
Permalink
Re: best practice: where to put constants [In reply to]

Jarom Smith wrote:
> In the end, this is what I decided to do because I have relatively few
> of these guys (so far) and I'd rather have them thrown together all in
> one place than spread all over the system. But I'm wondering if there
> is a best practice?
>
> I don't want to put them in the config hash or in a configuration file
> because these are not things that a user should be able to change or
> override.

Not sure this is the 'best practice' way of doing what you're trying to
achieve, but that aside - to answer your actual question:

I'd just put them all into their own package, and arrange for them to be
exportable, something like this:

package MyApp::Constants;
use strict;
use warnings;
use Exporter qw/import/;

use constant {
THING_FOO => 0,
THING_BAR => 1,
};

our @EXPORT = qw(
&THING_FOO
&THING_BAR
);

then just 'use MyApp::Constants;' where you need them, job done..

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


alejandro.imass at gmail

Jun 4, 2009, 8:38 AM

Post #3 of 14 (1361 views)
Permalink
Re: best practice: where to put constants [In reply to]

Although I think there is no best practice as such, I mean there are
many ways to do this in Perl in general, but Catalyst offers the nice
feature of the main config file in YAML, so I keep all my constants
and configuration values there.

YAML is so powerful that IMHO it's the best place not ony to store
your constants but to structure them intelligently. Of course, all the
constants you put in your YAML file will be vailable through
$c->config->{foo}

Best,
Alejandro Imass


On Fri, Jun 5, 2009 at 10:50 AM, Jarom Smith <jarom [at] jaromsmith> wrote:
> Hi all:
>
> This is probably my lack of Perl knowledge showing... but where would be
> the best-practice place to put constants in my code? I'm talking about
> magic numbers that I use internally but need to reference in multiple
> locations of the code. Things like
>
> "VENDOR_COMMIT" => 1,
> "VENDOR_DECLINE" => 2,
> "TIME_OUTSIDE_WINDOW" => 3,
>
> In Java I would declare them as "public static final" members the class
> that describes that particular object (in this case, a vendor
> notification) and I would refer to them like
>
> if (notification.getAction() == Notification.VENDOR_COMMIT) ....
>
> So I think the analog to that in Catalyst would be to define the
> constant(s) in the ResultSource classes that are automatically generated
> for me (below the line) and then refer to them like
>
> if ($notification->action ==
> MyApp::Schema::ResultSet::Notification::VENDOR_COMMIT) ....
>
> The problem with doing it that way is that the namespace starts to become
> unwieldly, and I have to remember where I put the thing I'm trying to
> reference. The alternative would be to put them at the top level, i.e., in
> MyApp.pm:
>
> use constant NOTIFICATION_VENDOR_COMMIT => 1;
> use constant NOTIFICATION_VENDOR_DECLINE => 2;
> use constant NOTIFICATION_TIME_OUTSIDE_WINDOW => 3;
>
> use constant NOTIFICATION_PROPERTY_ACCEPT => 1;
> use constant NOTIFICATION_PROPERTY_CANCEL => 2;
> use constant NOTIFICATION_PROPERTY_OFFER_NEW_WINDOW => 3;
>
> and then in the code I just say
>
> if ($notification->action == MyApp::VENDOR_COMMIT) ....
>
> In the end, this is what I decided to do because I have relatively few of
> these guys (so far) and I'd rather have them thrown together all in one
> place than spread all over the system. But I'm wondering if there is a best
> practice?
>
> I don't want to put them in the config hash or in a configuration file
> because these are not things that a user should be able to change or
> override.
>
> Thanks in advance for the advice/insight; this group has been a great help
> so far.
>
> jarom smith
> tech go-to guy
>
>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jarom at jaromsmith

Jun 4, 2009, 8:52 AM

Post #4 of 14 (1367 views)
Permalink
Re: best practice: where to put constants [In reply to]

Thanks t0m. I will do the MyApp::Constants thing, thanks for the idea.

But out of curiosity... in your opinion, what *would* be the "best
practice" way of doing what I'm trying to achieve? (or was your comment
"Not sure this is the 'best practice' way of doing what you're trying to
achieve" referring to my way of doing things, and your opinion of best
practice is the MyApp::Constants thing?) Yeah, it appears that is what
you meant...

I've been doing my thing in isolation for so long, I'm completely
disconnected from best practices, which is why I'm asking... that, and
I am a bit of a Perl hack. Being here is definitely raising my game!

jarom smith
tech go-to guy


Tomas Doran wrote:
> Not sure this is the 'best practice' way of doing what you're trying to
> achieve, but that aside - to answer your actual question:
>
> I'd just put them all into their own package, and arrange for them to be
> exportable, something like this:
>
> package MyApp::Constants;
> use strict;
> use warnings;
> use Exporter qw/import/;
>
> use constant {
> THING_FOO => 0,
> THING_BAR => 1,
> };
>
> our @EXPORT = qw(
> &THING_FOO
> &THING_BAR
> );
>
> then just 'use MyApp::Constants;' where you need them, job done..
>
> Cheers
> t0m
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jarom at jaromsmith

Jun 4, 2009, 8:55 AM

Post #5 of 14 (1367 views)
Permalink
Re: best practice: where to put constants [In reply to]

I thought about putting constants in $c->config, but decided not to
mostly because it would allow a malicious (or ignorant) user to
completely screw up my app. A constant should be, uh... constant!

I have been resisting learning YAML, mostly because I am learning so
many new things right now that I don't want to add one more thing to the
list... but I know I will have to dig in eventually.

jarom smith
tech go-to guy


Alejandro Imass wrote:
> Although I think there is no best practice as such, I mean there are
> many ways to do this in Perl in general, but Catalyst offers the nice
> feature of the main config file in YAML, so I keep all my constants
> and configuration values there.
>
> YAML is so powerful that IMHO it's the best place not ony to store
> your constants but to structure them intelligently. Of course, all the
> constants you put in your YAML file will be vailable through
> $c->config->{foo}
>
> Best,
> Alejandro Imass
>
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


lance at bearcircle

Jun 4, 2009, 9:14 AM

Post #6 of 14 (1368 views)
Permalink
Re: best practice: where to put constants [In reply to]

Alejandro Imass wrote:
> Although I think there is no best practice as such, I mean there are
> many ways to do this in Perl in general, but Catalyst offers the nice
> feature of the main config file in YAML, so I keep all my constants
> and configuration values there.
>
> YAML is so powerful that IMHO it's the best place not ony to store
> your constants but to structure them intelligently. Of course, all the
> constants you put in your YAML file will be vailable through
> $c->config->{foo}

I wouldn't put these constants in the applications main configuration
file unless the constants are for the application. Jarom's example
indicates the constants have to do with data coming from a model so I'd
put them in a package in the model's namespace. That way MVC separation
is maintained *and* you have access to the constants outside the
catalyst app if needed.

--[Lance]


--
GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
CACert.org Assurer

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Jun 4, 2009, 9:17 AM

Post #7 of 14 (1361 views)
Permalink
Re: best practice: where to put constants [In reply to]

Jarom Smith wrote:
> But out of curiosity... in your opinion, what *would* be the "best
> practice" way of doing what I'm trying to achieve? (or was your comment
> "Not sure this is the 'best practice' way of doing what you're trying to
> achieve" referring to my way of doing things, and your opinion of best
> practice is the MyApp::Constants thing?) Yeah, it appears that is what
> you meant...

No, it was more a note that I have no idea if your solution is the
correct one for the problem space (DBIC may already have a nicer way of
solving that - you may want to ask over there), but that is how I
implement your solution when appropriate.

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


alejandro.imass at gmail

Jun 4, 2009, 9:36 AM

Post #8 of 14 (1369 views)
Permalink
Re: best practice: where to put constants [In reply to]

<OT>
Yeah well, that is [TIMTOWTDI] the beauty of the Perl world, is
precisely that the is not _one_ best practice. Apart from Conway's
PBPs which a) apply to mostly any language anyway, and b) are just
that: _recommended_ PBPs, so it really doesn't contradict _the_ Zen of
Perl (pun intended), neither does Catalyst. So, the bottom line IMHO
is that there is and should not be a "best practice" for what your
looking for.
</OT>

On Fri, Jun 5, 2009 at 11:47 AM, Tomas Doran <bobtfish [at] bobtfish> wrote:
> Jarom Smith wrote:
>>
>> But out of curiosity... in your opinion, what *would* be the "best
>> practice" way of doing what I'm trying to achieve? (or was your comment
>> "Not sure this is the 'best practice' way of doing what you're trying to
>> achieve" referring to my way of doing things, and your opinion of best
>> practice is the MyApp::Constants thing?) Yeah, it appears that is what you
>> meant...
>
> No, it was more a note that I have no idea if your solution is the correct
> one for the problem space (DBIC may already have a nicer way of solving that
> - you may want to ask over there), but that is how I implement your solution
> when appropriate.
>
> Cheers
> t0m
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


alejandro.imass at gmail

Jun 4, 2009, 10:02 AM

Post #9 of 14 (1367 views)
Permalink
Re: best practice: where to put constants [In reply to]

Yes of course, makes sense. Besides constants should "use constant"
also. Nevertheless, it is quite common to confuse/abuse constants with
'configuration constants' which should go perfectly in your main yaml
config file. My bad for not clarifying this.

On Fri, Jun 5, 2009 at 11:44 AM, Lance A. Brown <lance [at] bearcircle> wrote:
> Alejandro Imass wrote:
>> Although I think there is no best practice as such, I mean there are
>> many ways to do this in Perl in general, but Catalyst offers the nice
>> feature of the main config file in YAML, so I keep all my constants
>> and configuration values there.
>>
>> YAML is so powerful that IMHO it's the best place not ony to store
>> your constants but to structure them intelligently. Of course, all the
>> constants you put in your YAML file will be vailable through
>> $c->config->{foo}
>
> I wouldn't put these constants in the applications main configuration
> file unless the constants are for the application. Jarom's example
> indicates the constants have to do with data coming from a model so I'd
> put them in a package in the model's namespace. That way MVC separation
> is maintained *and* you have access to the constants outside the
> catalyst app if needed.
>
> --[Lance]
>
>
> --
> GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
> CACert.org Assurer
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


ijw at cack

Jun 4, 2009, 10:07 AM

Post #10 of 14 (1359 views)
Permalink
Re: best practice: where to put constants [In reply to]

2009/6/4 Tomas Doran <bobtfish [at] bobtfish>:
> use constant {
>    THING_FOO => 0,
>    THING_BAR => 1,
> };


As we steadily go offtopic, I thought "use Readonly" was preferred
over "use constant" nowadays? Not that I remember the arguments why.
Anyone else have an opinion here?

--
Ian.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jjn1056 at yahoo

Jun 4, 2009, 10:09 AM

Post #11 of 14 (1364 views)
Permalink
Re: best practice: where to put constants [In reply to]

--- On Thu, 6/4/09, Tomas Doran <bobtfish [at] bobtfish> wrote:

> From: Tomas Doran <bobtfish [at] bobtfish>
> Subject: Re: [Catalyst] best practice: where to put constants
> To: "The elegant MVC web framework" <catalyst [at] lists>
> Date: Thursday, June 4, 2009, 11:31 AM
> Jarom Smith wrote:
> > In the end, this is what I decided to do because I
> have relatively few of these guys (so far) and I'd rather
> have them thrown together all in one place than spread all
> over the system.  But I'm wondering if there is a best
> practice?
> >
> > I don't want to put them in the config hash or in a
> configuration file
> > because these are not things that a user should be
> able to change or override.
>
> Not sure this is the 'best practice' way of doing what
> you're trying to achieve, but that aside - to answer your
> actual question:
>
> I'd just put them all into their own package, and arrange
> for them to be exportable, something like this:
>
> package MyApp::Constants;
> use strict;
> use warnings;
> use Exporter qw/import/;
>
> use constant {
>     THING_FOO => 0,
>     THING_BAR => 1,
> };
>
> our @EXPORT = qw(
>     &THING_FOO
>     &THING_BAR
> );
>
> then just 'use MyApp::Constants;' where you need them, job
> done..
>
> Cheers
> t0m
>

I do basically the same thing, except I use Sub::Exporter instead. Then I have a MyApp::Constants to go along with my MyApp::Types, which contain all my MooseX::Type based type constraints.

john

> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>




_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jarom at jaromsmith

Jun 4, 2009, 10:23 AM

Post #12 of 14 (1349 views)
Permalink
Re: best practice: where to put constants [In reply to]

Hi John:

You lost me. I could probably figure out what you are saying, but would
you be willing to send some sample code illustrating what you're talking
about? That would be very helpful to me, and possibly others. Thanks!

jarom smith
tech go-to guy


John Napiorkowski wrote:
> I do basically the same thing, except I use Sub::Exporter instead. Then I have a MyApp::Constants to go along with my MyApp::Types, which contain all my MooseX::Type based type constraints.
>
> john
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


mihai at bazon

Jun 4, 2009, 11:01 AM

Post #13 of 14 (1349 views)
Permalink
Re: best practice: where to put constants [In reply to]

I'm doing pretty much the same thing, although I dislike the fact that
declaring/exporting constants tends to be very verbose. You have to name
those constants both in "use constant" and when declaring them in
EXPORT_OK and/or EXPORT_TAGS.

The following sample is what suits me best for now:

package TF::Constants;

use strict;
use warnings;

use base 'Exporter';

our %PERMISSIONS;
our %ERRORS;

our %EXPORT_TAGS = (
perms => [ keys %PERMISSIONS ],
errors => [ keys %ERRORS ]
);

our @EXPORT_OK = map { @$_ } values %EXPORT_TAGS;

$EXPORT_TAGS{all} = \@EXPORT_OK;

### "use constant" implies a BEGIN block, so unless we declare our
### variables in a BEGIN block they won't be defined by the time
### constant::import is called. Still learning Perl quirks after 8
### years.

BEGIN {

%PERMISSIONS = (

TF_PERM_EXEC_OTHER => 1,
TF_PERM_WRITE_OTHER => 2,
TF_PERM_READ_OTHER => 4,

TF_PERM_EXEC_GROUP => 8,
TF_PERM_WRITE_GROUP => 16,
TF_PERM_READ_GROUP => 32,

TF_PERM_EXEC_USER => 64,
TF_PERM_WRITE_USER => 128,
TF_PERM_READ_USER => 256,

TF_PERM_DEFAULT => 0664, # rw-rw-r--

);

%ERRORS = (
TF_ERR_NOPERMS => 'NOPERMS',
);

}

use constant \%PERMISSIONS;
use constant \%ERRORS;

1;

That is in short: declare some global (our) hashes, that contain your
constants. Then define them in a BEGIN block. Then pass reference to
those hashes to use constant and finally, use some map/keys tricks to
export them automatically (not having to list each name again is a big
win for my lazy ass).

Cheers,
-Mihai

PS: yes this is totally unrelated to Catalyst. :-)

Tomas Doran bobtfish [at] bobtfish wrote:

> Jarom Smith wrote:
>
>> In the end, this is what I decided to do because I have relatively few of
>> these guys (so far) and I'd rather have them thrown together all in one
>> place than spread all over the system. But I'm wondering if there is a
>> best practice?
>>
>> I don't want to put them in the config hash or in a configuration file
>> because these are not things that a user should be able to change or
>> override.
>
> Not sure this is the 'best practice' way of doing what you're trying to
> achieve, but that aside - to answer your actual question:
>
> I'd just put them all into their own package, and arrange for them to be
> exportable, something like this:
>
> package MyApp::Constants; use strict; use warnings; use Exporter
> qw/import/;
>
> use constant { THINGFOO => 0, THINGBAR => 1, };
>
> our @EXPORT = qw( &THINGFOO &THINGBAR );
>
> then just 'use MyApp::Constants;' where you need them, job done..
>
> Cheers t0m
>
> ------------------------------------------------------------------------
>
> List: Catalyst [at] lists Listinfo:
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable
> archive: http://www.mail-archive.com/catalyst [at] lists/ Dev
> site: http://dev.catalyst.perl.org/


moseley at hank

Jun 4, 2009, 12:14 PM

Post #14 of 14 (1349 views)
Permalink
Re: best practice: where to put constants [In reply to]

On Thu, Jun 04, 2009 at 10:23:11AM -0700, Jarom Smith wrote:
>
> You lost me. I could probably figure out what you are saying, but would
> you be willing to send some sample code illustrating what you're talking
> about? That would be very helpful to me, and possibly others. Thanks!

Jarom,

To add one more to the mix, I put all configuration data into the
Catalyst config file, but constants that might be used outside of
Catalyst are in a Const.pm file that can be loaded by model classes.

The vast majority of settings are in my Catalyst config, and I end up
with very few in the Const.pm file. Mostly things like database
constants are in Const.pm. (Plus, I have utilities to make the
Catalyst config available to non-Catalyst scripts, like cron jobs).


In any module that needs a constant it's then:

package MyApp::Model::Foo;

# Import "ACTIVE PENDING DISABLED"
use MyApp::Const ':user_status';

...

if ( $user->status == PENDING ) {
...
}

You could probably alter code below so that the constants have a
prefix of "USER_STATUS_" to give the feeling of name spaces.

The problem with this approach is that these constants are
subroutines. See "perldoc Readonly" for discussion about this.


Here's an abbreviated example. You can do the same thing just using
Exporter but this gave me a bit more flexibility on building my
constants.



package MyApp::Const;
use strict;
use warnings;
use Carp;

my %constants_map = (

account_type => {
SUBSCRIPTION => 1,
PREPAID => 2,
GROUP => 3,
},

user_status => {
ACTIVE => 1,
PENDING => 2,
DISABLED => 3,
},
);

my %by_name;

# Create a flat list of constants and look for duplicates

for my $group_name ( keys %constants_map ) {
for my $const ( keys %{ $constants_map{$group_name} } ) {
die "Constant $const name already used" if exists $by_name{$const};
$by_name{$const} = $constants_map{$group_name}{$const};
}
}


# Export constants to caller name space

sub import {
my ( $self, @export ) = @_;

my $caller_pkg = caller || die 'no caller';

no strict 'refs'; ## no critic

for my $name ( @export ) {
if ( $name =~ s/^:// ) {
my $group = $constants_map{$name} || carp "Constant group ':$name' not found";
for my $const ( keys %{$group} ) {
my $sub_name = $caller_pkg . '::' . $const;
*{$sub_name} = sub() { $group->{$const} };
}
}

else {
croak "Constant '$name' not found" unless exists $by_name{$name};
my $sub_name = $caller_pkg . '::' . $name;
*{$sub_name} = sub() { $by_name{$name} };
}
}

return;

}


1;

--
Bill Moseley.
moseley [at] hank
Sent from my iMutt

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.