[Catalyst] Catalyst::Manual v5.8000 Now On CPAN

[Darren Duncan]

hkclark at gmail.com wrote:
> A new version of Catalyst::Manual has been posted to CPAN.  Although
> we don't yet have a lot of Catalyst 5.80-specific material just yet
> (there is some initial information at
> http://search.cpan.org/perldoc?Catalyst::Manual::CatalystAndMoose --
> Please send in any contributions you might have!), I have tested
> everything in the tutorial against 5.8004, so we have bumped the
> version number of Catalyst::Manual to 5.8XXX as well

Thanks.  As someone who intends to begin using Catalyst with the 5.8+ series, 
its nice to have documentation focused on the new best practices.

> But the important changes in this release include:
> 
>   * Plural DB table names are now singular.  Many thanks to
>         Kiffin Gish (krg) for all the help on that effort!

This may be bike-shedding and no big deal, but I think this was better the old 
way.  A table represents info on a collection of items, and is best named after 
what the collection as a whole is, such as 'books', 'authors', 'book_authors', 
etc, same as how you'd name an array variable in Perl.  Instead, 'book' or 
'author' etc is best used as the name of a variable containing a single row from 
said table, such as with "for my $book (@books) {...}".

Now more important than that however, I recommend updating the examples so that 
all of the id columns are named 'foo_id' consistently rather than 'foo_id' in 
some places and 'id' in others, where it makes sense.  In this case, 'book' 
should have 'book_id' and 'author' should have 'author_id'.  One reason for this 
is that you can then easily do a natural join between the 3 tables, or between 
any applicable 2 tables, and the rows would match up as they should, and result 
columns would have distinct names, whereas with your current naming you'd have 
to write an explicit join condition to make them match up and explicit column 
renames to identify which 'id' you're looking at in a resultset or view.  The 
benefits of such a naming scheme go beyond that, and would seem to outweigh any 
benefits of naming them all 'id'.  The point is it is more natural and a best 
readability and maintainability practice for like things to have like names and 
unlike things to have different names.

-- Darren Duncan