If you use other modules along with CGI.pm and any of those other modules export a function whose name is the same as an HTML tag name, then you'll have to have either CGI.pm or that other module not export that particular function. The object notation allows CGI.pm to not export tons of symbols while providing you an easy way to get to all of the CGI routines.

You could probably also use CGI::td() to similar effect, though that may raise issues of which sub-module each routine comes from -- since I haven't see this documented I wouldn't consider it supported and so wouldn't recommend it. I just mention this because it is the other standard way to avoid collisions in your global namespace.

Usually object notation is a good thing for Perl modules because it allows you to not pollute your global name space with lots of imported functions that may clash as you use more modules. It is also good because it usually gets the module author to allow multiple simultaneous uses of that module with different configurations.

I find it hard to image a case where one script would need more than one CGI object. So it is just a matter of trade-off of not having to type $q-> vs. not having your global namespace "polluted" with tons of short names.

• When I'm unsure if saying use CGI qw(:standard) will collide with existing subroutines, such as grafting a CGI front onto some previous command-line program
• In a mod_perl environment, to keep from creating 240 stabs (as we discussed earlier in a thread about CGI.pm's performance) in each Apache::Registry-managed handler
• When I want to have more than one CGI object in a single program (to save and restore parameters to persistant storage, for example)

-- Randal L. Schwartz, Perl hacker