Menu
▾
▴
nms-cgi-devel
|
From: Olivier D. <dr...@sh...> - 2002-01-28 22:33:37
|
On Mon, Jan 28, 2002 at 09:39:26PM +0000, Jonathan Stowe wrote:
> In the first place I really am not going to be the
> one who goes through the code altering the places where these variables
> are interpolated into quoted strings, which really would mean assigning
> their values to new variables rather than some @{[EMULATE_MATTS_CODE()]}
> hack ... and then there is the documentation and the support issues :)
I've (in a subtle way maybe) proposed myself to do it, in which case the
"it's a lot of work" argument doesn't really hold for anybody but me
(unless someone would like to help) and since I'm in favor of the
change, the argument isn't really *against* anything.
-Oli
--
+----------------------------------------------+
| Olivier Dragon dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+
|
|
From: Joseph F. R. <rya...@os...> - 2002-01-28 23:12:25
|
First of all, I don't think that we should change config variables to
constants. The original MWS didn't use constants as the config, and I
don't think we should either. It provides no further benefit for the
program, and it could only lead to confusion when a non-perl programmer
tries to edit the config.
Secondly, the use of subs to create constants like that is ridiculous. Try
the constant pragma :)
use constant DEBUGGING => 0;
use constant EMULATE_MATTS_CODE => 0;
use constant MAILPROG => '/usr/lib/sendmail -oi -t';
Joseph Ryan
At 05:37 PM 1/28/2002 -0500, Olivier Dragon wrote:
>On Mon, Jan 28, 2002 at 09:39:26PM +0000, Jonathan Stowe wrote:
> > In the first place I really am not going to be the
> > one who goes through the code altering the places where these variables
> > are interpolated into quoted strings, which really would mean assigning
> > their values to new variables rather than some @{[EMULATE_MATTS_CODE()]}
> > hack ... and then there is the documentation and the support issues :)
>
>I've (in a subtle way maybe) proposed myself to do it, in which case the
>"it's a lot of work" argument doesn't really hold for anybody but me
>(unless someone would like to help) and since I'm in favor of the
>change, the argument isn't really *against* anything.
>
>-Oli
>
>--
>+----------------------------------------------+
>| Olivier Dragon dr...@sh... |
>| Software Engineering II, McMaster University |
>+----------------------------------------------+
>
>_______________________________________________
>Nms-cgi-devel mailing list
>Nms...@li...
>https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
|
|
From: Olivier D. <dr...@sh...> - 2002-01-28 23:29:53
|
On Mon, Jan 28, 2002 at 06:07:55PM -0500, Joseph F. Ryan wrote: > Secondly, the use of subs to create constants like that is ridiculous. Try > the constant pragma :) > > use constant DEBUGGING => 0; > use constant EMULATE_MATTS_CODE => 0; > use constant MAILPROG => '/usr/lib/sendmail -oi -t'; I wouldn't say that using it is ridiculous to use subroutines to create constants, but this alternative seems reasonable. Is is in the standard library of 5.004_04? Does this integrate in strings as easily as a normal variable, eg. print "Mail program is MAILPROG"; ? In this case it would make this approach much more appealing I think. -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Nick C. <ni...@cl...> - 2002-01-28 23:43:16
|
On Mon, Jan 28, 2002 at 06:34:07PM -0500, Olivier Dragon wrote:
> On Mon, Jan 28, 2002 at 06:07:55PM -0500, Joseph F. Ryan wrote:
> > Secondly, the use of subs to create constants like that is ridiculous. Try
> > the constant pragma :)
> >
> > use constant DEBUGGING => 0;
> > use constant EMULATE_MATTS_CODE => 0;
> > use constant MAILPROG => '/usr/lib/sendmail -oi -t';
>
> I wouldn't say that using it is ridiculous to use subroutines to create
> constants, but this alternative seems reasonable. Is is in the standard
> library of 5.004_04? Does this integrate in strings as easily as a
> normal variable, eg.
use constant works in 5.00404, but it is a little messy to
interpolate it into a string.
> print "Mail program is MAILPROG";
print "Mail program is @{[ MAILPROG ]}";
The big problem (with both constants and subs) is that it makes
the config section of the script look a bit different, and we're
aiming to make it very easy for users with no technical skills to
change from Matt's version to ours by copying their config over.
--
Nick
|
|
From: Olivier D. <dr...@sh...> - 2002-01-29 00:19:50
|
On Mon, Jan 28, 2002 at 11:42:58PM +0000, Nick Cleaton wrote: > The big problem (with both constants and subs) is that it makes > the config section of the script look a bit different, and we're > aiming to make it very easy for users with no technical skills to > change from Matt's version to ours by copying their config over. True. But I think if it *looks* like it, then normal people will realize that we're just making things "better" because MWS are "bad" which is also, I think, one of the goal of this project. On the other hand, at least for formmail--I haven't looked at any others yet--the configuration setting is *MUCH* different from MWS. Putting 3-4 line comments between each config variables resulting in about 4 pages of config for about 5-10 parameters definetly makes it very *HARD* for newbies. And what is the configuration isn't clear either. There are impossible to notice "Configuration" and "End Configuration" comments burried under a pile of other comments which really belong in the README. I've been a newbie not so long ago and MWS, although bad, had all of the config parameters together, one line after the other; all of this enclosed in very visible "Configuration - this is all you need to modify to get the script working" comments placed near the top of the script; not after a few pages of log, which I think belong in a seperate file. I'm not trying to critisize anybody's work here. I know that nothing is finished yet--in fact most scripts have alpha or beta attached to them. I'm simply trying to make a point that using "use constant" instead of scalar is a better way of doing thing, and I don't see it being an issue for readability and MWS users' friendliness. Oppositely, I would see it as more user friendly. As a diet-coke of newbie I'd say that if comments are clear, you can put things any way you want. -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
Thanks for helping keep SourceForge clean.
X