|
From: Dave C. <da...@da...> - 2002-01-29 13:33:47
|
I'd like to thank Olivier for getting some discussion going on a number of topics. Here are my opinions[1] on some of the subjects he's raised. * Constants It would be great if we could replace the variables with constants (because that's what they really are). However, the idea of creating constants as subroutines really doesn't work for me. It makes constants work too differently to variables (particularly with respect to interpolatation in double-quoted strings). It would almost certainly confuse our targer audience (not to mention new developers on the project). The "use const NAME => value" pragma is simply a shortcut way of creating subroutine constants. Even if it was supported in 5.004_04, I would still not want to use it. * New documents Yep. Collecting those docs an putting on the web site (and, I guess, in CVS) is a good plan. Let's kick them around for a couple of days and I'll put them on the site towards the end of the week. Does anyone have any comments on the docs as they stand? We're talking about the "How to become an nms developer" and "Rules for nms code" documents that Olivier extracted from my emails. * Program header comments I really like the idea of doing this, but on the other hand, I really don't like Olivier's suggestions. I'd go for something a bit more lightweight. Like this: #!/usr/bin/perl -wT # # ProgramName.pl v1.2.3.4.5.6... # # This program is licensed in the same way as Perl # itself. You are free to choose between the GNU Public # License <http://www.gnu.org/licenses/gpl.html> or # the Artistic License # <http://www.perl.com/pub/a/language/misc/Artistic.html> # # For a list of changes see CHANGELOG # # For help on configuration or installation see README # use strict; use ...; . . . # # USER CONFIGURATION SECTION # # Modify these to your own settings. You might have to # contact your system administrator if you do not run # your own web server. If the purpose of these # parameters seems unclear, please see the README file. # my $param = 'stuff'; # Will be used for stuff my $baseurl = '/var/www'; # Server's web documents directory my ...; . . . # # END USER CONFIGURATION # (no user servicable parts beyond here) # * CHANGELOG file I totally agree that tha changelog will soon be too big to have in the code files. The idea of a separate CHANGELOG file sounds great to me. If a CVS guru could point me at the magic invocation to create the CHANGELOG file auto-magically as part of the release process then I'd be even happier. Hope that makes sense. All comments welcome. Dave... [not speaking ex-cathredra] [1] And that's all they are - my _opinions_. I'm not laying down the law here. -- Don't dream it... be it |