object Perl

Steve Waldman swaldman at mchange.com
Mon Aug 9 23:11:26 CDT 1999

Web applications are an instructive example.

As you suggest, in a simple CGI model, all this "OO" crap just seems
like extra syntax mucking up the works.

But consider -- CGI was rev 0, the very simplest possible interface for
using the web as an interface to applications rather than a glorified
way of ftp'ing text files.

In the simple CGI model, there is a single HTTP request, and it is your
job to construct a single HTTP response. Treating the request and
response info as global state works fine under this model.

But CGI's simple approach -- one request, one response, one process --
is inadequate for high-performance web applications. If you'd like many
requests to share expensive resources -- database connection handles
spring to mind -- all of that request/response state for all those
clients is gonna have to live in the address space of a single running
process. All of a sudden, you have to start asking the question "which
response am I manipulating?" or "which request am I extracting
parameters from?"

Of course, you could make a global hashtable and manage this yourself.
But you'd find the procedural syntax looking ugly, fast. Being able to
simply create a $cgi_obj and manipulate its variables without affecting
the state of the hundred other simultaneous requests will seem very
elegant by comparison.

OO stuff is all about structure -- there is nothing you can do with OO
that you couldn't do without it. For very simple, one-off problems, OO
stuff is just extra baggage. But as problems get more complex, or if
your simple things might be reused in large, complicated systems, it
starts to make a lot of sense to create walls that segregate data and to
organize subsystems in to types that people can understand without
remembering all the internals. The marginal cost of the extra syntax
diminishes as the size and complexity of the system grows.


Craig Freter wrote:
> At last weeks meeting we discussed the difference between using the CGI
> module with either the object interface, or the procedural interface.  I
> created a simple CGI using both the object interface and procedural
> interface of CGI.pm.
> I think the procedural interface is easier to read.  Let find out what
> the rest of you think.
> First the object interface.
> # import nothing
> use CGI;
> # create CGI object
> my $cgi_obj = new CGI;
> # call CGI object methods inside of print function
> print
>     $cgi_obj->header,
>     $cgi_obj->start_html(-title   => 'Baltimore Perl Mongers',
>                          -BGCOLOR => 'white'),
>     $cgi_obj->h1('Baltimore Perl Mongers'),
>     $cgi_obj->hr,
>     $cgi_obj->h3('Perl Mongers is a not-for-profit organization
>         whose mission is to establish Perl user groups'),
>     $cgi_obj->end_html;
> ...and now the procedural interface.
> # import functions in tags 'standard' and 'html3'
> use CGI qw(:standard :html3);
> # use CGI functions inside of print function
> print
>     header,
>     start_html(-title   => 'Baltimore Perl Mongers',
>                -BGCOLOR => 'white'),
>     h1('Baltimore Perl Mongers'),
>     hr,
>     h3('Perl Mongers is a not-for-profit organization
>         whose mission is to establish Perl user groups'),
>     end_html;
> --
> All that is complex is not useful,
> and all that is useful is simple.
>                        -- Mikhail Kalashnikov

More information about the Baltimore-pm mailing list