From ggoebel at goebel.ws Fri Nov 18 06:51:13 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Fri, 18 Nov 2005 08:51:13 -0600 (CST) Subject: [PBP-pm] Test: ping... Message-ID: ...ping From ggoebel at goebel.ws Fri Nov 18 18:07:28 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Fri, 18 Nov 2005 20:07:28 -0600 (CST) Subject: [PBP-pm] PBP::Table Suggestions Message-ID: I've been spending time recently munging the results of database queries into html tables. I found myself working with: o column _and_ row headers o calculating sums o adding cells calculated from cells relative to the record o formatting cell data o wrapping cell data with forms so a click will use the cell's and/or other record data as criteria for a drill down query o collating summarized results of multiple queries into new tables o pivots >From the existing CPAN modules: Data::Table (http://search.cpan.org/~ezdb/Data-Table-1.43/) Data::Tabular (http://search.cpan.org/~gam/Data-Tabular-0.24/) I can see a need to support: o output tables as text, csv, html, xml o clone tables o merge tables by columns or rows o sort by column or row o group by with aggregates o add, insert, delete, change ordering of columns or rows o select matching columns or rows Are there any other CPAN module anyone would suggest I look at? I'm not particularly interested in reinventing a database or spreadsheet in Perl, though I'd probably be interested in any CPAN modules you could recommend that take a go at implementing them. Really, I would just like to take a go at writing a nice flexible module for dealing with tabular data written to PBP standards. I've mocked up an interface, but would like to cast the net wider before I settle in to the task... cheers, Garrett From srj at email.unc.edu Fri Nov 18 19:27:34 2005 From: srj at email.unc.edu (Stuart Jefferys) Date: Fri, 18 Nov 2005 22:27:34 -0500 Subject: [PBP-pm] Named constants from modules? Message-ID: This is my first post here. Hope it works... The Conway PBP book recommends using named constants in place of magic numbers. This is a standard practice across many languages. The "Readonly" module is suggested as way to make these constants really constant. However, the book also recommends against allowing export of any variables from modules. I agree in principle, but as named constants are implemented as variables the two practices are at odds. If that was the limit of the problem, I would just skip the recommendations and export "named constant" variables when needed. However, there is a convenient package for exporting subroutines from a module (Perl6::Export::Attrs) that *explicitly* avoids allowing the export of variables. This seems very 'un-perlish', and actually prevents me from using the package to do something I believe to be unquestionably correct. I have added a "request for feature" to that module on CPAN to allow export of named constants if they are read only. Anyone have any thoughts on this? Also, I have never tried it, but it just occurred to me -- what happens upon export of "Readonly" tagged variables anyway? "Physics, mathematics, and chemistry - they are all just frameworks. Biology is different because it's the content that matters." Stuart Jefferys - Graduate student UNC - Curriculum in Genetics and Molecular Biology; UNC - Bioinformatics and Computational Biology From paul.barry at itcarlow.ie Sat Nov 19 03:58:16 2005 From: paul.barry at itcarlow.ie (Paul Barry) Date: Sat, 19 Nov 2005 11:58:16 +0000 Subject: [PBP-pm] Book review of PBP Message-ID: <1132401496.8932.7.camel@localhost.localdomain> Just joined this list - what a great idea. And ... I've just finished working through PBP for the second time. It is full of very useful stuff. I've written a review of it for Linux Journal, which is accessible here: http://www.linuxjournal.com/article/8567 Looking forward to hearing other Perl programmers' views on the content of this important book. Paul. -- Paul Barry paul.barry at itcarlow.ie http://glasnost.itcarlow.ie/~barryp/ Institute of Technology, Carlow, Ireland From ajsavige at yahoo.com.au Sat Nov 19 05:26:32 2005 From: ajsavige at yahoo.com.au (Andrew Savige) Date: Sun, 20 Nov 2005 00:26:32 +1100 (EST) Subject: [PBP-pm] Book review of PBP In-Reply-To: <1132401496.8932.7.camel@localhost.localdomain> Message-ID: <20051119132632.80668.qmail@web36112.mail.mud.yahoo.com> --- Paul Barry wrote: > I've written a review of it for Linux Journal, which is > accessible here: > > http://www.linuxjournal.com/article/8567 Which reminds me I did an article on PBP a while back: http://www.perlmonks.org/?node_id=500556 and gave a talk to Sydney.pm, the (crappy) slides available here: http://perl.net.au/download/pbp-slides.tar.gz I'm interested to hear opinions on: 1) What new guidelines would you like to see added to the book? 2) What guidelines do you disagree with or not follow? PBP is already a large book and it's somewhat arbitrary to decide how many "non Perl" tips (e.g. use a revision control system) to put in such a book. That said, and as mentioned in the perlmonks node above, I'd enjoy reading new guidelines on: * "Use an automated (one action) build system" * "Invest in code reviews" * "Design and write error-safe code" * "Don't pessimize prematurely" * Tips on coding for concurrency * Tips on coding for portability * Tips on "Orthogonality and the DRY principle" * Tips on communication in software teams * Tips on using static and dynamic code analysis tools As for guidelines I disagree with, while I found the funky new modules fascinating, I feel some of them are not *yet* mature and proven enough to be classified as "best practice". For example, last I heard, Class::Std cannot be used in multi-threaded and mod_perl environments ... and there were some glitches reported with version.pm and the PAUSE indexer: http://www.perlmonks.org/?node_id=504425 http://rt.cpan.org/NoAuth/Bug.html?id=14782 http://www.perlmonks.org/?node_id=503983 Oh, and the implementation of the "In-situ arguments" guideline on page 304 needs tightening up as dicussed in: http://www.perlmonks.org/?node_id=488824 /-\ Send instant messages to your online friends http://au.messenger.yahoo.com From ggoebel at goebel.ws Sun Nov 20 06:26:15 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Sun, 20 Nov 2005 08:26:15 -0600 (CST) Subject: [PBP-pm] Book review of PBP In-Reply-To: <20051119132632.80668.qmail@web36112.mail.mud.yahoo.com> Message-ID: Nice reviews. On Sun, 20 Nov 2005, Andrew Savige wrote: > > I'm interested to hear opinions on: > > 1) What new guidelines would you like to see added to the book? How to write threadsafe code. But you've already got that covered with "Tips on coding for concurrency" and your concerns with Class::Std's thread safety issues. It looks like the mod_perl's CHECK block issue will be cleared up in the next release. > 2) What guidelines do you disagree with or not follow? The guideline on multi-contextual return values (ch9, subroutines). I disagree with encouraging a finer granularity of context sensitivity without discouraging subroutines as contextual homonyms. Programmers are used to getting different results from different inputs. But we're not that used to the idea of return value context as one of those inputs. Personally, in cases where no single return value is appropriate for a list returning subroutine... I'd rather see an object returned so the DWIM aspect is dropped in favor of self-documenting code: my ($status_obj) = get_server_status($server_ID); my $load = $status_obj->get_NUM(); my $is_up = $status_obj->get_BOOL(); my $summary = $status_obj->get_STR(); Which would look nicer if the accessors were aliased to be more descriptive: my $load = $status_obj->load(); my $is_up = $status_obj->is_up(); my $summary = $status_obj->summary(); cheers, Garrett From ggoebel at goebel.ws Sun Nov 20 07:08:12 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Sun, 20 Nov 2005 09:08:12 -0600 (CST) Subject: [PBP-pm] Named constants from modules? In-Reply-To: Message-ID: On Fri, 18 Nov 2005, Stuart Jefferys wrote: > This is my first post here. Hope it works... welcome. > The Conway PBP book recommends using named constants in place of > magic numbers. ... > However, the book also recommends against allowing export > of any variables from modules. True, but scalars, arrays and hashes created with Readonly aren't variable variables. So the interface variable prohibition on making variables part of a modules interface wouldn't really apply. The reasoning behind that prohibition is that you want to control exposure of a module's internal state, access to that state, and how it can be changed. None of those reasons apply to the non-modifiable "variables" constructed with Readonly. In your wishlist request, you wrote: > For instance, if I have a module of physics constants, and want to use > them by name in a calling module. Which sounds reasonable. > Also, I have never tried it, but it just occurred to me -- what > happens upon export of "Readonly" tagged variables anyway? package Foo; use Readonly; use base qw(Exporter); use vars qw($FOO); our @EXPORT = qw($FOO); Readonly $FOO = 3.14; package main; Foo->import(); print qq{$FOO\n};" $FOO=1; results in: 3.14 Modification of a read-only value attempted at ... cheers, Garrett From ggoebel at goebel.ws Tue Nov 22 06:09:13 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Tue, 22 Nov 2005 08:09:13 -0600 (CST) Subject: [PBP-pm] Reviewing PBP recommended modules? Message-ID: Would people be interested in a PBP code review of existing modules? I intend to start with the modules that were created for PBP. Then move on to the CPAN and Core modules recommended in the book. My goals in doing this would be: o learn from existing code o refactor internals to bring roughly into line with PBP submitting doc and code patches to maintainers o refactor interfaces where needed and submit to CPAN under PBP::* o port to Perl6 (pugs) Damian, do you already have plans for the PBP namespace on CPAN? Any suggestions on a more appropriate namespace? Would you welcome a constructive review of the PBP modules? Note: I expect to have a significant amount of time to dedicate to this task in the upcoming year: the better part of January and at least 2 days a week from there on out. cheers, Garrett From simonm at cavalletto.org Tue Nov 22 06:39:05 2005 From: simonm at cavalletto.org (Matthew Simon Cavalletto) Date: Tue, 22 Nov 2005 09:39:05 -0500 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <3141DD17-4720-4079-B7C5-1694B0145953@cavalletto.org> On Nov 22, 2005, at 9:09 AM, C. Garrett Goebel wrote: > My goals in doing this would be: > o learn from existing code > o refactor internals to bring roughly into line with PBP > submitting doc and code patches to maintainers This all sounds very helpful... > o refactor interfaces where needed and submit to CPAN under PBP::* ... except for this part. I would urge you to consider posting these modules into the namespaces that make sense based on what the modules do, rather than grouping them together based on an aspect of their implementation. For example, if you rewrite a command-line options parser, it would be better to file it under Getopt::*, where people looking for an options parser are more likely to find it, rather than PBP::CmdLine, where only people who know there's a PBP implementation are likely to look. Just my $0.02... -Simon From j_bence at mac.com Tue Nov 22 06:47:05 2005 From: j_bence at mac.com (James Bence) Date: Tue, 22 Nov 2005 06:47:05 -0800 Subject: [PBP-pm] Class::Std alternative - Object::InsideOut Message-ID: <0c2d1de50fdf1b1e76c43789fed0b3cc@mac.com> Hi: I was browsing recently and ran across Object::InsideOut, which supplies the functionality of Class::Std, plus it can be used in threaded code and in 5.6.0 and later. It does work as advertised, using arrays instead of hashes for storage. It's a little bit more work to get class fields set up, as you have to indicate which fields are mandatory (and I have already forgotten to do that more than once), but along with the mandatory flag you can specify required formats (e.g., must be a number). I mailed a patch to Damian to make Class::Std mostly work under 5.6.0; there were two issues if I recall correctly, one involving variable interpolation inside a variable to be used as a sprintf format string, and the other involving the inheritance tree. The first made things crash, and the second one you could live with if you knew about it. I got an automated reply; I think Damian might be busy, to put it mildly ... if there is interest in the patch, I can post it here. The patch doesn't help Class::Std to work under threads. James From Rob_Biedenharn at alum.mit.edu Tue Nov 22 06:56:20 2005 From: Rob_Biedenharn at alum.mit.edu (Rob Biedenharn) Date: Tue, 22 Nov 2005 09:56:20 -0500 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: <3141DD17-4720-4079-B7C5-1694B0145953@cavalletto.org> References: <3141DD17-4720-4079-B7C5-1694B0145953@cavalletto.org> Message-ID: <6.2.5.6.0.20051122094332.02218e08@alum.mit.edu> At 11/22/2005 09:39 AM, you wrote: >On Nov 22, 2005, at 9:09 AM, C. Garrett Goebel wrote: > > > My goals in doing this would be: > > o learn from existing code > > o refactor internals to bring roughly into line with PBP > > submitting doc and code patches to maintainers > >This all sounds very helpful... > > > o refactor interfaces where needed and submit to CPAN under PBP::* > >... except for this part. > >I would urge you to consider posting these modules into the >namespaces that make sense based on what the modules do, rather than >grouping them together based on an aspect of their implementation. > >For example, if you rewrite a command-line options parser, it would >be better to file it under Getopt::*, where people looking for an >options parser are more likely to find it, rather than PBP::CmdLine, >where only people who know there's a PBP implementation are likely to >look. > >Just my $0.02... > >-Simon I agree with Simon on the PBP:: namespace idea. Perhaps a separate export tag if an alternate interface is suggested by PBP (not that I can thing of such a situation right now). It would be nice to have a hint in the code that PBP was used and its recommendations for formatting and style should be preserved, but it would not necessarily be helpful for existing code to "break" simply as a result of an interface changing. # use PBP qw(layout references regexp); -Rob Rob Biedenharn (C) 513-295-4739 (H) 513-677-2172 http://alum.mit.edu/www/rob_biedenharn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/pbp-pm/attachments/20051122/29414c9c/attachment.html From chris at clotho.com Tue Nov 22 07:04:09 2005 From: chris at clotho.com (Chris Dolan) Date: Tue, 22 Nov 2005 09:04:09 -0600 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <51084D35-B4B0-49C5-970F-F9D6C4641E70@clotho.com> On Nov 22, 2005, at 8:09 AM, C. Garrett Goebel wrote: > Would people be interested in a PBP code review of existing modules? The Perl::Critic project is trying to do this in an automated fashion. It implements a generic infrastructure, plus a collection of policies. Many of the current policies are inspired by PBP. We could use some help implementing more of the policies. SVN and mailing lists: http://perlcritic.tigris.org/ Released versions: http://search.cpan.org/dist/Perl-Critic Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) From ggoebel at goebel.ws Tue Nov 22 09:42:45 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Tue, 22 Nov 2005 11:42:45 -0600 (CST) Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: <6.2.5.6.0.20051122094332.02218e08@alum.mit.edu> Message-ID: On Tue, 22 Nov 2005, Rob Biedenharn wrote: > At 11/22/2005 09:39 AM, Simon wrote: > >On Nov 22, 2005, at 9:09 AM, C. Garrett Goebel wrote: > > > > > My goals in doing this would be: > > > o learn from existing code > > > o refactor internals to bring roughly into line with PBP > > > submitting doc and code patches to maintainers > > > >This all sounds very helpful... > > > > > o refactor interfaces where needed and submit to CPAN under PBP::* > > > >... except for this part. > > > >I would urge you to consider posting these modules into the > >namespaces that make sense based on what the modules do, rather than > >grouping them together based on an aspect of their implementation. Like Perl6::* ? One of the reasons I'd like to see a PBP:: namespace is that assuming functional requirements have been met, I would prefer to use modules which consistently apply the same documentation, style, idiom, testing... in short, everything that constitutes coding practices. I assume I am not alone in this. CPAN being what it is... how do you suggest someone find modules which bill themselves as PBP conformant? With PBP::, when I head over to http://search.cpan.org, type in Getopt, and am faced with 30+ modules, I'd at least be able to quickly focus in on the ones in the ^PBP:: namespace. That being said, I'm not wedded to PBP::. But I'm not yet convinced that it'd be unwise to use it. > >For example, if you rewrite a command-line options parser, it would > >be better to file it under Getopt::*, where people looking for an > >options parser are more likely to find it, rather than PBP::CmdLine, > >where only people who know there's a PBP implementation are likely to > >look. The thought was to change the module name as little as possible... Which would you prefer: o Getopt::CmdLine::PBP? o Getopt::PBP::Cmdline o PBP::Getopt::CmdLine The first leaves the module name mostly intact, but forces it into someone else's namespace while scattering the PBP designation to the four winds. The second puts PBP modules at a branch of the namespace heirarchy where it may arguably be easier to find. But fragments the module name itself, and the PBP designation across namespaces branches. The last allows all the PBP modules to be found from one starting point, and otherwise leaves the module name intact. > I agree with Simon on the PBP:: namespace idea. Perhaps a separate > export tag if an alternate interface is suggested by PBP (not that I > can thing of such a situation right now). How about all the modules which use global variables for configuration? Or the older ones which recommend object construction like: $t = new Data::Table($data, $header, 0); My guess is that the interfaces of a large portion of Core and CPAN modules aren't PBP kosher... I'm excited to learn of Perl::Critic. Perhaps the first thing I'll try to do with it is run it against Core Perl modules just to get an idea of what we're up against. > It would be nice to have a hint in the code that PBP was used and its > recommendations for formatting and style should be preserved, but it > would not necessarily be helpful for existing code to "break" simply > as a result of an interface changing. I don't expect many CPAN maintainers to be interested in applying internals-only patches to bring their modules into line with PBP recommendations. Perhaps I'll be surprised. I wouldn't consider asking a maintainer to apply non-backward compatible changes in a module's interface. PBP::* would be for PBP module refactoring which makes a break with backward compatibility. cheers, Garrett From rhesa at cpan.org Tue Nov 22 09:37:59 2005 From: rhesa at cpan.org (Rhesa Rozendaal) Date: Tue, 22 Nov 2005 18:37:59 +0100 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <43835777.7080803@cpan.org> C. Garrett Goebel wrote: > I'm excited to learn of Perl::Critic. Perhaps the first thing I'll try to > do with it is run it against Core Perl modules just to get an idea of what > we're up against. I'd be interested to see what that turns up... > I don't expect many CPAN maintainers to be interested in applying > internals-only patches to bring their modules into line with PBP > recommendations. Perhaps I'll be surprised. The kwalitee game seems to suggest otherwise. And I suspect the same pro and con arguments in that area will pop up here too. > I wouldn't consider asking a maintainer to apply non-backward compatible > changes in a module's interface. PBP::* would be for PBP module > refactoring which makes a break with backward compatibility. While that may make an interesting theoretical exercise, I doubt anyone will want to write programs against them. Package names are long enough already, generally speaking. I don't think this reads well at all: use PBP::LWP::UserAgent; use PBP::HTTP::Request::Common; use PBP::SOAP::Lite::Transport::TCP; use PBP::Template::Plugin::GD::Graph::area; use PBP::CGI::Application::Plugin::DevPopup::HTTPHeaders; That's 9 common characters at the start of each line! Pretty soon, you'd be forced to violate the 78 columns practice ;) my 2 ?re, Rhesa From schoon at amgt.com Tue Nov 22 09:33:14 2005 From: schoon at amgt.com (Mark Schoonover) Date: Tue, 22 Nov 2005 09:33:14 -0800 Subject: [PBP-pm] Reviewing PBP recommended modules? Message-ID: C. Garrett Goebel wrote: > On Tue, 22 Nov 2005, Rob Biedenharn wrote: >> At 11/22/2005 09:39 AM, Simon wrote: >>> On Nov 22, 2005, at 9:09 AM, C. Garrett Goebel wrote: >>> The thought was to change the module name as little as possible... > > Which would you prefer: > o Getopt::CmdLine::PBP? > o Getopt::PBP::Cmdline > o PBP::Getopt::CmdLine I prefer the third one. It still retains the original name of the module, so you know what it does. Prepending the PBP:: to it won't change that fact. Thanks! Mark Schoonover IS Manager American Geotechnical v - 714-685-3900 f - 714-685-3909 If there's a 50-50 chance something can go wrong, then 9 out of 10 times it will." -- Yogi Berra From simonm at cavalletto.org Tue Nov 22 09:54:11 2005 From: simonm at cavalletto.org (Matthew Simon Cavalletto) Date: Tue, 22 Nov 2005 12:54:11 -0500 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <24CDC279-FD2B-4915-B6A8-9BF1CC769ED2@cavalletto.org> On Nov 22, 2005, at 12:42 PM, C. Garrett Goebel wrote: >> At 11/22/2005 09:39 AM, Simon wrote: >> >>> I would urge you to consider posting these modules into the >>> namespaces that make sense based on what the modules do, rather than >>> grouping them together based on an aspect of their implementation. > > One of the reasons I'd like to see a PBP:: namespace is that assuming > functional requirements have been met, I would prefer to use modules > which consistently apply the same documentation, style, idiom, > testing... > in short, everything that constitutes coding practices. Agreed. > CPAN being what it is... how do you suggest someone find modules which > bill themselves as PBP conformant? Searching for PBP is easy enough: http://search.cpan.org/search?m=all&n=100&q=pbp > Which would you prefer: > o Getopt::CmdLine::PBP? > o PBP::Getopt::CmdLine > > The first leaves the module name mostly intact, but forces it into > someone > else's namespace while scattering the PBP designation to the four > winds. > > The last allows all the PBP modules to be found from one starting > point, and otherwise leaves the module name intact. I'd prefer the first, and the existing PBP-style equivalents already published to CPAN seem to use this approach: Module::Starter::PBP and ExtUtils::ModuleMaker::PBP. Existing CPAN convention seems to suggest that if you are creating a new-but-different equivalent of a module named X, it should be called X::Foo. (For example, a pure-Perl implementation of an XS module is often named X::PurePerl.) Having a bunch of modules named Foo::X and Foo::Y tends to suggest that they're part of a framework, and specifically intended for use within that framework. (For example, people have made smaller versions of Class::MethodMaker that only include the features they need, named Foo::MethodMaker.) > I don't expect many CPAN maintainers to be interested in applying > internals-only patches to bring their modules into line with PBP > recommendations. Perhaps I'll be surprised. Maybe... Certainly there are a lot of random throw-away modules which aren't really maintained and for which patches are more likely to be ignored, but I suspect that the authors of the more popular modules are likely to be more open to documentation and code style patches. -Simon From silver at phoenyx.net Tue Nov 22 09:51:20 2005 From: silver at phoenyx.net (Karen J. Cravens) Date: Tue, 22 Nov 2005 11:51:20 -0600 (CST) Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: On Tue, 22 Nov 2005, C. Garrett Goebel wrote: CGG>CPAN being what it is... how do you suggest someone find modules which CGG>bill themselves as PBP conformant? Most emphatically: by some other way than namespace. I really, really, really don't want to have modules leaping out from under my code merely because they became PBP conformant. CGG>With PBP::, when I head over to http://search.cpan.org, type in Getopt, CGG>and am faced with 30+ modules, I'd at least be able to quickly focus in on CGG>the ones in the ^PBP:: namespace. If CPAN-as-is can't find them with its search, then I think the answer is to change (or overlay) CPAN, rather than change all the Perl code in the world that uses any given module. (Did I mention that I don't like it when module names change?) -- Karen J. Cravens silver at phoenyx.net From ggoebel at goebel.ws Tue Nov 22 11:39:41 2005 From: ggoebel at goebel.ws (C. Garrett Goebel) Date: Tue, 22 Nov 2005 13:39:41 -0600 (CST) Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: Message-ID: On Tue, 22 Nov 2005, Karen J. Cravens wrote: > On Tue, 22 Nov 2005, C. Garrett Goebel wrote: > > CGG>CPAN being what it is... how do you suggest someone find modules which > CGG>bill themselves as PBP conformant? > > Most emphatically: by some other way than namespace. What other way? > I really, really, really don't want to have modules leaping out > from under my code merely because they became PBP conformant. Refactoring a module without breaking backward compatibility could be fed as a set of patches to the module's maintainer. Assuming they're willing to take them: no name changes involved. Non-backward compatible refactorings would break existing code. This is clearly an unacceptable option unless the module's maintainer defines a clear schedule of depreciating one interface in favor of another (like POE does); cheers, Garrett From silver+pbp at phoenyx.net Tue Nov 22 11:23:44 2005 From: silver+pbp at phoenyx.net (Karen) Date: Tue, 22 Nov 2005 13:23:44 -0600 (CST) Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: On Tue, 22 Nov 2005, C. Garrett Goebel wrote: CGG>What other way? Well, uh, almost any other way. CPAN's soundex makes searching a bit more adventurous than sometimes it ought to be, but if there's some sort of standardization in noting the PBPness in the pod then we still ought to be able to figure the searches out. And if not, well, a PBP project a la annoCPAN, where we externally index the PBPish modules, is certainly possible. CGG>Refactoring a module without breaking backward compatibility could be fed CGG>as a set of patches to the module's maintainer. Assuming they're willing CGG>to take them: no name changes involved. Right... but then you're back to finding out those modules are PBPish in some other manner than namespace. CGG>Non-backward compatible refactorings would break existing code. This is CGG>clearly an unacceptable option unless the module's maintainer defines a CGG>clear schedule of depreciating one interface in favor of another (like POE CGG>does); Yeah, I suppose saying "if it can't be refactored with backward compatibility, it was probably a module you shouldn't have been using in the first place" doesn't work, huh? But seriously: if all modules *should* be PBPical at some future date, then I think tacking PBP into the namespace, fore *or* aft, is counterproductive, even for wholly new modules. (And that's outside my bias against module name *changes*, mind.) From darren at DarrenDuncan.net Tue Nov 22 21:14:08 2005 From: darren at DarrenDuncan.net (Darren Duncan) Date: Tue, 22 Nov 2005 21:14:08 -0800 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: A few miscellaneous replies ... I strongly disagree with the idea of putting "PBP" in a module name just to say that it is conformant to what the book says. Module names should fit based on their function mainly, and minor implementation details shouldn't factor in. In fact, doing this would by itself violate a best naming practice. If you want to have modules searchable by conformability, you can accomplish that if the modules mention it in their documentation, since CPAN lets you search for things based on their documentation. In regards to the Perl6::* modules, their name choice is based on a different situation than finding PBP conformability. They are specifically about implementing Perl 6 core language features in Perl 5; using these are conceptually like using features that should be in the core language but aren't. By contrast, most of CPAN is about extensions and add-ons, features that are conceptually not part of the core language. And so they are named according to their add-on functionality type. Separately, I do support the idea of working with CPAN module authors to improve their modules, including making them more like PBP recommends. I would certainly want people to do that for my modules; despite my own efforts to apply PBP to my new work, I inevitably miss some good things. -- Darren Duncan From fxn at hashref.com Tue Nov 22 21:34:41 2005 From: fxn at hashref.com (Xavier Noria) Date: Wed, 23 Nov 2005 06:34:41 +0100 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: On Nov 23, 2005, at 6:14, Darren Duncan wrote: > A few miscellaneous replies ... > > I strongly disagree with the idea of putting "PBP" in a module name > just to say that it is conformant to what the book says. Module > names should fit based on their function mainly, and minor > implementation details shouldn't factor in. In fact, doing this > would by itself violate a best naming practice. I second that. > If you want to have modules searchable by conformability, you can > accomplish that if the modules mention it in their documentation, > since CPAN lets you search for things based on their documentation. Even if it claimed to be PBP comformant I would still wonder to _which_ subset of PBP it is conformant. Different modules will follow different subsets, so the homogeneity some see in a "PBP" marker is going to be there modulus what the author chose to comply with, that's a too weak homogeneity to deserve a marker in my view. I would leave PBP to influence authors by itself, to percolate in the way they publish modules, and have as a secondary effect a better CPAN. -- fxn From damian at conway.org Wed Nov 23 23:51:35 2005 From: damian at conway.org (Damian Conway) Date: Thu, 24 Nov 2005 18:51:35 +1100 Subject: [PBP-pm] Named constants from modules? In-Reply-To: References: Message-ID: <43857107.10004@conway.org> >>However, the book also recommends against allowing export >>of any variables from modules. > > True, but scalars, arrays and hashes created with Readonly aren't > variable variables. > > So the interface variable prohibition on making variables part > of a modules interface wouldn't really apply. The reasoning behind that > prohibition is that you want to control exposure of a module's > internal state, access to that state, and how it can be changed. > > None of those reasons apply to the non-modifiable "variables" constructed > with Readonly. This is certainly true. I will review the guideline and the Perl6::Export::Attrs module with a view to allowing it. Damian From damian at conway.org Wed Nov 23 23:57:06 2005 From: damian at conway.org (Damian Conway) Date: Thu, 24 Nov 2005 18:57:06 +1100 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <43857252.9060709@conway.org> > Damian, do you already have plans for the PBP namespace on CPAN? No. I agree with the other posters who thought the modules were better placed in their "native" namespaces. I would like to see a mechanism that allowed people to judge how compliant modules were. But perhaps that mechanism is just Test::Perl::Critic (a module I greatly admire!) > Would you welcome a constructive review of the PBP modules? Sure. I *always* welcome constructive feedback. Patches even more! ;-) But don't expect them to meet my own guidelines in all cases. Remember that I say that one should depart from those suggestions only after careful consideration. The modules I created are about changing the Perl language rather than solving a given problem, so I often needed to depart from Best Practice in order to get the "internals" to work. Damian From pmh at edison.ioppublishing.com Thu Nov 24 02:37:10 2005 From: pmh at edison.ioppublishing.com (Peter Haworth) Date: Thu, 24 Nov 2005 10:37:10 +0000 Subject: [PBP-pm] Reviewing PBP recommended modules? Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.pm.org/pipermail/pbp-pm/attachments/20051124/cda64661/attachment.pl From sagarshah at softhome.net Thu Nov 24 23:54:55 2005 From: sagarshah at softhome.net (Sagar Shah) Date: Fri, 25 Nov 2005 07:54:55 +0000 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <1132905295.4228.2.camel@orinoco> On Thu, 2005-11-24 at 10:37 +0000, Peter Haworth wrote: > On Tue Nov 22 11:39:41 PST 2005, C. Garrett Goebel wrote: > > On Tue, 22 Nov 2005, Karen J. Cravens wrote: > > > On Tue, 22 Nov 2005, C. Garrett Goebel wrote: > > > > > > CGG>CPAN being what it is... how do you suggest someone find > > > CGG>modules which bill themselves as PBP conformant? > > > > > > Most emphatically: by some other way than namespace. > > > > What other way? > > How about bundles? There could be a separate Bundle::PBP::category for > each category that we care to recommend modules in. Since bundles are > essentially just documentation, there's plenty of scope for including > explanations, comparisons, non-recommendations, etc. This is the best suggestion imho. Modules should remain in their native namespaces and their names should not be 'polluted' by a PBP tag. A bundle distribution can be maintained to list all PBP 'compliant'/'refactored' modules. Introducing a PBP tag might be unfair to other module authors who have/will stuck to best practices as per the book but don't want to rename their module. -- Sagar Shah From pmh at edison.ioppublishing.com Fri Nov 25 02:38:36 2005 From: pmh at edison.ioppublishing.com (Peter Haworth) Date: Fri, 25 Nov 2005 10:38:36 +0000 Subject: [PBP-pm] Reviewing PBP recommended modules? References: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.pm.org/pipermail/pbp-pm/attachments/20051125/a06c796c/attachment.pl From alfiejohn at flamebait.org Thu Nov 24 14:55:00 2005 From: alfiejohn at flamebait.org (Alfie John) Date: Fri, 25 Nov 2005 09:55:00 +1100 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: References: Message-ID: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> On 24/11/2005, at 9:37 PM, Peter Haworth wrote: > On Tue Nov 22 11:39:41 PST 2005, C. Garrett Goebel wrote: >> On Tue, 22 Nov 2005, Karen J. Cravens wrote: >>> On Tue, 22 Nov 2005, C. Garrett Goebel wrote: >>> >>> CGG>CPAN being what it is... how do you suggest someone find >>> CGG>modules which bill themselves as PBP conformant? >>> >>> Most emphatically: by some other way than namespace. >> >> What other way? > > How about bundles? There could be a separate Bundle::PBP::category for > each category that we care to recommend modules in. Since bundles are > essentially just documentation, there's plenty of scope for including > explanations, comparisons, non-recommendations, etc. Usually when I go to CPAN, I am there to get a module and use it. I have no intention of pulling it apart. I think that having a PBP namespace for the sake of having a namespace is kind of silly. Just because it follows a BP doesn't mean it works! Maybe what is needed is a new option in 'make dist' when building distributions to show that it follows *a* PBP? Alfie From andy at petdance.com Tue Nov 29 07:53:26 2005 From: andy at petdance.com (Andy Lester) Date: Tue, 29 Nov 2005 09:53:26 -0600 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> References: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> Message-ID: <20051129155326.GG3054@petdance.com> On Fri, Nov 25, 2005 at 09:55:00AM +1100, Alfie John (alfiejohn at flamebait.org) wrote: > Maybe what is needed is a new option in 'make dist' when building > distributions to show that it follows *a* PBP? Take a look at CPANTS. xoxo, Andy -- Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance From chris at clotho.com Tue Nov 29 07:56:56 2005 From: chris at clotho.com (Chris Dolan) Date: Tue, 29 Nov 2005 09:56:56 -0600 Subject: [PBP-pm] Reviewing PBP recommended modules? In-Reply-To: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> References: <55F74A40-2FC0-438E-8C99-A5E7FB89AAD3@flamebait.org> Message-ID: On Nov 24, 2005, at 4:55 PM, Alfie John wrote: > > Usually when I go to CPAN, I am there to get a module and use it. I > have no intention of pulling it apart. I think that having a PBP > namespace for the sake of having a namespace is kind of silly. Just > because it follows a BP doesn't mean it works! > > Maybe what is needed is a new option in 'make dist' when building > distributions to show that it follows *a* PBP? In my opinion the best way to document this is in POD. In my modules, I'm starting to document the version of Perl::Critic that I've used to validate the distribution. Someday perhaps this could be a field in META.yml. To do that, we would have to invent some notation to indication which coding style was employed (e.g. a list of Test::Perl::Critic policies that pass). Note: I am definitely not advocating this idea, just tossing it out there. Personally, I'm MUCH more interested in the test coverage of a module than its coding style. I think the former is a better indicator of quality, although I do believe the latter is highly valuable for ease- of-use. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)