Re^4: strict/do question

Importing the symbols into :: or main:: is exactly what I want (there is no package). The script I'm aiming for has zero-configuration, i.e. all the stuff that can change is set in a cfg file that is held within a sandbox controlled under CVS, which I'm do'ing". Most of these variables need to be in global (or in package, if there was one) scope, as they need to be read by most of the subroutines in main. Ideally what I want is #include "import.pl" but for reasons in the article above this isn't really there, unless you do some funky odd looking stuff with the DB module. I'd rather avoid funky odd looking stuff for this software as lots of people need to use and understand it. I do find it odd that an old C-coder like Larry W would choose not to give people the ability to #include. Someone alluded to the idea that do'ing a file is kinda unsafe - presumably because you could be sucking up any old kind of stuff there which could break the main program? But I think I'm right in saying that unless the main program has use $variable then having the same in the file which is done then the symbol will not be put into :: or main::? I've thought of writing modules and so forth here, but then I truly get into different lexical scopes, which I'm trying to avoid for simplicity sake. (Read simplicity=50% laziness , 50% easy for non-perlers to understand). Thanks, dch.

Comment on Re^4: strict/do question Select or Download Code

Replies are listed 'Best First'.
Re^5: strict/do question by blazar (Canon) on Nov 25, 2006 at 08:36 UTC
Importing the symbols into :: or main:: is exactly what I want (there is no package). You can still do that in a more conventional and only slightly more complex way by writing a proper module and exporting only what you really need to. Polluting `main::` is just a bad idea in any case. Ideally what I want is #include "import.pl" but for reasons in the article above this isn't really there, unless you do some funky odd looking stuff with the DB module. I'd rather avoid funky odd looking stuff for this software as lots of people need to use and understand it. I do find it odd that an old C-coder like Larry W would choose not to give people the ability to #include. Perl's convention to include stuff is to use modules. There are appearently simpler alternatives on which use itself is actually built, and there are situations in which one may actually want to resort to them. For example in golf you may want to do a file. But you're not golfing. When wanting to use a module to be decided at runtime based upon some condition, then you want to require and manually `import()`. But that's not your case either. And so on... I've thought of writing modules and so forth here, but then I truly get into different lexical scopes, which I'm trying to avoid for simplicity sake. (Read simplicity=50% laziness , 50% easy for non-perlers to understand). Thanks, dch. Don't be misleaded by a wrong concept of simplicity. Do not aim for maximum simplicity, since chances are that it will bite you in the neck later on, revealing itself to only be appearently simple. I am aware of YAGNI, but there's stuff it's easy to know in advance YareGN, and even if it weren't so in some particular situation, it would in most common ones, thus getting the habit of doing so would raise the risk of making that into a bad programming habit. Aim for the Right® amount simplicity. Also, as Perl programmers we all know that Laziness is a cardinal virtue, but IMHO not really as of itself only.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: strict/do question
by blazar (Canon) on Nov 25, 2006 at 08:36 UTC

Importing the symbols into :: or main:: is exactly what I want (there is no package).

You can still do that in a more conventional and only slightly more complex way by writing a proper module and exporting only what you really need to. Polluting main:: is just a bad idea in any case.

Ideally what I want is #include "import.pl" but for reasons in the article above this isn't really there, unless you do some funky odd looking stuff with the DB module. I'd rather avoid funky odd looking stuff for this software as lots of people need to use and understand it. I do find it odd that an old C-coder like Larry W would choose not to give people the ability to #include.

Perl's convention to include stuff is to use modules. There are appearently simpler alternatives on which use itself is actually built, and there are situations in which one may actually want to resort to them. For example in golf you may want to do a file. But you're not golfing. When wanting to use a module to be decided at runtime based upon some condition, then you want to require and manually import(). But that's not your case either. And so on...

I've thought of writing modules and so forth here, but then I truly get into different lexical scopes, which I'm trying to avoid for simplicity sake. (Read simplicity=50% laziness , 50% easy for non-perlers to understand). Thanks, dch.

Don't be misleaded by a wrong concept of simplicity. Do not aim for maximum simplicity, since chances are that it will bite you in the neck later on, revealing itself to only be appearently simple. I am aware of YAGNI, but there's stuff it's easy to know in advance YareGN, and even if it weren't so in some particular situation, it would in most common ones, thus getting the habit of doing so would raise the risk of making that into a bad programming habit. Aim for the Right® amount simplicity.

Also, as Perl programmers we all know that Laziness is a cardinal virtue, but IMHO not really as of itself only.

[reply]
[d/l]
[select]