Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > configurable variables in own file?

Reply
Thread Tools

configurable variables in own file?

 
 
ivowel@gmail.com
Guest
Posts: n/a
 
      10-24-2007

Dear perl experts: I want to create a rather lightweight package that
just uses what is installed in standard perl. this problem must be
very common.

package mypackage:
require Exporter;
our @ISA= qw(Exporter);
our @EXPORT = qw( v1 v2 v3 v4 );
our ($v1, $v2, $v3, $v4) = ("user-please-set", "a", "b", "c");
($v1=~ /whatisit/);
## a lot more stuff, a lot more variables, etc.

so far so good. alas, I now realize that $v1 is something that I
would like my package users to change. instead of leaving it in
mypackage, I think it would be nice to have such variables layed out
into mypackageconfig.pm . mypackage should just load in
mypackageconfig.pm at compile time, and treat everything in it as its
own---like the C preprocessor #include.

optimally, I would like syntax like

package mypackage:
require Exporter;
our @ISA= qw(Exporter);
our @EXPORT = qw( v1 v2 v3 v4 );
include mypackageconfig;
our ($v2, $v3, $v4) = ("a", "b", "c");
($v1=~ /whatisit/);
## a lot more stuff, a lot more variables, etc.

and the file mypackageconfig would just contain

our $v1= "user-please-set";

is there a standard way to do this? I have been trying to accomplish
this, but always run into import/export problems.

sincerely,

/iaw

 
Reply With Quote
 
 
 
 
Michele Dondi
Guest
Posts: n/a
 
      10-24-2007
On Wed, 24 Oct 2007 03:29:32 -0000, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

>optimally, I would like syntax like
>
>package mypackage:


Just don't use all lowercase, since these

>require Exporter;
>our @ISA= qw(Exporter);
>our @EXPORT = qw( v1 v2 v3 v4 );
>include mypackageconfig;



>our ($v2, $v3, $v4) = ("a", "b", "c");
>($v1=~ /whatisit/);
>## a lot more stuff, a lot more variables, etc.
>
>and the file mypackageconfig would just contain
>
>our $v1= "user-please-set";
>
>is there a standard way to do this? I have been trying to accomplish
>this, but always run into import/export problems.


I can't see what problem could you possibly incur with require(), or
even do(). I don't see that you really need to import or export
anything, but which problems anyway?


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
 
 
 
Ben Morrow
Guest
Posts: n/a
 
      10-24-2007

Quoth (E-Mail Removed):
>
> Dear perl experts: I want to create a rather lightweight package that
> just uses what is installed in standard perl. this problem must be
> very common.
>
> package mypackage:
> require Exporter;
> our @ISA= qw(Exporter);
> our @EXPORT = qw( v1 v2 v3 v4 );
> our ($v1, $v2, $v3, $v4) = ("user-please-set", "a", "b", "c");
> ($v1=~ /whatisit/);
> ## a lot more stuff, a lot more variables, etc.
>
> so far so good. alas, I now realize that $v1 is something that I
> would like my package users to change. instead of leaving it in
> mypackage, I think it would be nice to have such variables layed out
> into mypackageconfig.pm . mypackage should just load in
> mypackageconfig.pm at compile time, and treat everything in it as its
> own---like the C preprocessor #include.
>
> optimally, I would like syntax like
>
> package mypackage:


This line has a syntax error. Please copy-and-paste the *actual* code
you have run.

Also, don't use all-lowercase package names. These are reserved for
pragmas. It's probably better not to use top-level namespaces (those
without :: in) either, as the chance of conflict with some other
installed module is high. Choose some sensible top-level package for
your app, and keep everything under that. I tend to use BMORROW::* for
'private' modules I don't intend to distribute, where BMORROW is my CPAN
id.

> require Exporter;
> our @ISA= qw(Exporter);
> our @EXPORT = qw( v1 v2 v3 v4 );
> include mypackageconfig;
> our ($v2, $v3, $v4) = ("a", "b", "c");
> ($v1=~ /whatisit/);
> ## a lot more stuff, a lot more variables, etc.
>
> and the file mypackageconfig would just contain
>
> our $v1= "user-please-set";
>
> is there a standard way to do this? I have been trying to accomplish
> this, but always run into import/export problems.


If you want to use a separate package, you can use something like

package MyPackage::Config;

require Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw($v1 $v2 $v3);

our $v1 = 'foo';
our $v2 = 'bar';
our $v3 = 'baz';

__END__

package MyPackage;

use MyPackage::Config;

# now $v1 etc. have been imported into MyPackage

__END__

If you don't like all the mess at the top of MyPackage/Config.pm, you
could simply put the variables in it and load it with 'do' instead. In
that case you should not name it '.pm', as it is no longer a Perl
module.

A better (cleaner, safer) solution would be to use a proper data format.
You can use something like YAML::Tiny or Config::Tiny, and if you
*really* want to avoid any external dependencies, both those modules are
pure-Perl (they don't require a compiler to install) and have no
dependencies themselves, so you can include them directly in your own
file, like this:

package MyPackage;

use warnings;
use strict;

BEGIN {

# This persuades perl that we've actually loaded Config::Tiny
$INC{'Config/Tiny.pm'} = $0;

# copy and paste here Config/Tiny.pm, from

package Config::Tiny;

# up to

__END__

}
BEGIN { Config::Tiny->import }

Ben

 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      10-25-2007
On Wed, 24 Oct 2007 13:19:54 +0200 Michele Dondi <(E-Mail Removed)> wrote:

MD> I can't see what problem could you possibly incur with require(), or
MD> even do(). I don't see that you really need to import or export
MD> anything, but which problems anyway?

Importing code just because you need data is an unnecessary security and
maintenance risk. To import data structures from an external
configuration file, the OP should use XML, YAML, a DB backend,
AppConfig, or any other mechanism specifically designed for that
purpose. I find AppConfig best for readable configurations, and YAML
best for complex data structures.

As an added benefit, with most of these there will be one place (a
logical configuration root) where configuration data can be found, so
you don't have $path and $mode and $another_config_variable all over the
code.

require() and do() should be reserved for importing Perl code.

Ted
 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      10-25-2007
On Wed, 24 Oct 2007 03:29:32 -0000 (E-Mail Removed) wrote:

i> optimally, I would like syntax like

i> package mypackage:
i> require Exporter;
i> our @ISA= qw(Exporter);
i> our @EXPORT = qw( v1 v2 v3 v4 );
i> include mypackageconfig;
i> our ($v2, $v3, $v4) = ("a", "b", "c");
i> ($v1=~ /whatisit/);
i> ## a lot more stuff, a lot more variables, etc.

i> and the file mypackageconfig would just contain

i> our $v1= "user-please-set";

With AppConfig:

V1 = user-please-set
# V2 is a hash
V2 key1 = value1
V2 key2 = value2
# V3 is a list
V3 = one
V3 = two
V3 = three

YAML and XML can do this as well. YAML will handle multi-level hashes
and lists, while XML may be better depending on your environment. Any
one of them is easily parseable by other languages as well--don't limit
your data to just Perl interpretation.

The method you described has security and maintenance risks, and is not
portable.

Ted
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      10-25-2007
On Thu, 25 Oct 2007 05:29:43 -0500, Ted Zlatanov <(E-Mail Removed)>
wrote:

>MD> I can't see what problem could you possibly incur with require(), or
>MD> even do(). I don't see that you really need to import or export
>MD> anything, but which problems anyway?
>
>Importing code just because you need data is an unnecessary security and
>maintenance risk. To import data structures from an external
>configuration file, the OP should use XML, YAML, a DB backend,
>AppConfig, or any other mechanism specifically designed for that
>purpose. I find AppConfig best for readable configurations, and YAML
>best for complex data structures.
>
>As an added benefit, with most of these there will be one place (a
>logical configuration root) where configuration data can be found, so
>you don't have $path and $mode and $another_config_variable all over the
>code.
>
>require() and do() should be reserved for importing Perl code.


Granted, but I was just answering his literal question.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      10-25-2007
On Thu, 25 Oct 2007 15:55:59 +0200 Michele Dondi <(E-Mail Removed)> wrote:

MD> On Thu, 25 Oct 2007 05:29:43 -0500, Ted Zlatanov <(E-Mail Removed)>
MD> wrote:

MD> I can't see what problem could you possibly incur with require(), or
MD> even do(). I don't see that you really need to import or export
MD> anything, but which problems anyway?
>>
>> Importing code just because you need data is an unnecessary security and
>> maintenance risk. To import data structures from an external
>> configuration file, the OP should use XML, YAML, a DB backend,
>> AppConfig, or any other mechanism specifically designed for that
>> purpose. I find AppConfig best for readable configurations, and YAML
>> best for complex data structures.
>>
>> As an added benefit, with most of these there will be one place (a
>> logical configuration root) where configuration data can be found, so
>> you don't have $path and $mode and $another_config_variable all over the
>> code.
>>
>> require() and do() should be reserved for importing Perl code.


MD> Granted, but I was just answering his literal question.

I think it's important to see beyong the literal question. As with the
OP here, often the real need (separate configuration from code) was
hidden by the immediate need (how do I import Perl code).

Ted
 
Reply With Quote
 
ivowel@gmail.com
Guest
Posts: n/a
 
      10-25-2007

thank you everybody. I also had hidden was that I do want at least
one short sub in the configuration that an enduser should be able to
change. therefore, layout out the variables to a data file, an
obvious solution, would not work for me.

I am not particularly fond of requiring my more naive users to start
using CPAN. yes, I love CPAN for my own use, but I don't want them to
get into potential dependency issues. I want to use only modules that
come with the standard perl distribution. It is just a personal
choice, that I don't expect anyone else to share.

regards,

/ivo

 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      10-26-2007
On Thu, 25 Oct 2007 23:50:24 -0000 (E-Mail Removed) wrote:

i> thank you everybody. I also had hidden was that I do want at least
i> one short sub in the configuration that an enduser should be able to
i> change.

As long as you understand that this means that the end user can make
your program do anything at all (including break it completely so it
won't run unless you take very specific precautions), this is fine.

In my experience making the end users edit code simply means they will
call you or someone like you to help them. I try to avoid that
situation by planning for the users' needs and abstracting them into
configuration options.

i> therefore, layout out the variables to a data file, an obvious
i> solution, would not work for me.

I don't know why you and many others insist on merging the notions of
configuration (pure data) and code (which includes code configuration).

Let the user write code your program will run if you wish, but at least
consider what it means to ask a user to learn Perl in order to configure
your program (for an example, consider what happens when the user tries
to use a dollar sign or a backslash, or what happens with a string like
"$var's").

i> I am not particularly fond of requiring my more naive users to start
i> using CPAN.

But you're OK asking them to write Perl code to configure your program?

i> yes, I love CPAN for my own use, but I don't want them to get into
i> potential dependency issues. I want to use only modules that come
i> with the standard perl distribution. It is just a personal choice,
i> that I don't expect anyone else to share.

Avoiding the use of CPAN is, to say the least, backwards. You can
always freeze a CPAN module with your program if you can't stand the
idea of software maintenance. Are you aware that the core 5.8, for
instance, contains modules that were not in 5.6? Does that mean you
won't use the 5.8 core modules to avoid dependency issues? Do you avoid
interactions with databases (the DBI module and related code)? How do
you justify to yourself and to your employers avoiding the use of
Regexp::Common, for example, just because you're not fond of relying on
CPAN?

Don't hide behind the "personal choice." That's nonsense. Avoiding
CPAN is a bad decision that can only be justified by a paranoid company
policy, but not by personal fondness (especially if you're paid for your
work).

Ted
 
Reply With Quote
 
Michele Dondi
Guest
Posts: n/a
 
      10-26-2007
On Thu, 25 Oct 2007 23:50:24 -0000, (E-Mail Removed) wrote:

>thank you everybody. I also had hidden was that I do want at least
>one short sub in the configuration that an enduser should be able to
>change. therefore, layout out the variables to a data file, an
>obvious solution, would not work for me.
>
>I am not particularly fond of requiring my more naive users to start
>using CPAN. yes, I love CPAN for my own use, but I don't want them to


Your users are naive enough to have potential problems using CPAN, yet
they are expected to be knowledgeable enough as to write a Perl sub?
Now, this sounds somewhat strange...


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Configurable Web Form James ASP .Net 1 11-11-2005 06:30 PM
Need good configurable forum... suggestion? VB Programmer ASP .Net 1 10-14-2005 08:21 PM
Setting a configurable time-out setting for all the communication initiated with Remoting object. Srinivasa Raghavan Sethuraman ASP .Net 0 06-30-2004 10:05 AM
Configurable Entity Statement rAinStorms VHDL 1 02-16-2004 10:31 AM
Configurable hardware thro' VHDL dutta VHDL 0 08-13-2003 01:33 PM



Advertisments