In the Java world, components are a set of (usually) tightly coupled classes coupled with a standardized API for the component itself. This API allows components to interact with each other in a standard way: initialization, registration of functionality, reflection, etc. The component idea is a next natural step in the hierarchical organization of a program:

• statements group into blocks
• blocks group into functions
• functions group into classes
• classes group into components

At each stage in this hierarchy, some data is hidden and/or encapsulated and there is some API to be used in programming the next higher level in the category.

What Perl components might be out there? At first I thought of the Tk set of modules for GUI development; those modules are surely a tightly-coupled set of classes. But the Tk API is very nearly a linear superposition of the individual class APIs, with no component level API in sight. Perhaps a better example is the set of POE::Component::* modules in the POE distributed computing framework. In POE distributed computing takes place by means of agents running on (usually) separate machines and interacting according to a common standardized protocol. In the Java parlance, the agents correspond to components with the protocol as a component API. Generalizing, web services or other service-oriented architectures implemented in Perl may effectively have components as their distributed elements.

Components are a nice organizing principle, but what can you do with them that you cannot do with classes? Well, the existence of a standardized container API allows containers to be incorporated into a program in a standard, uniform manner. This naturally leads to a plugin architecture for your program. In a program, one component is designated as a master control and serves as a container into which all other components plug in. A large application with amorphous bag of dozens of classes is transformed into an orderly set of containers corresponding the major subsystems, interacting in a uniform manner.

A well-known example of a component-based plugin architecture is the Eclipse project. Eclipse is an integrated development environment that is organized around a container into which editor, debugger, class browser, version control, etc. components are plugged in. Eclipse is highly modular and flexible. Although components were created initially for Java, components for C/C++ and even Perl are being developed.

In Perl, POE embraces the idea of plugins in the form of agents. There are other frameworks such as CGI::Application that allow for a component-based plugin architecture, but don't really require it.

If components are a reasonable idea and some Perl software is already making use of component ideas, why is there so little talk of component-based development in Perl? Is there something about Perl that obviates the need for multi-class structure? Is it just that most perl programs are below the complexity threshold needed for components to be compelling? Thoughts?

I think it would be cool for a Perl component API to be developed, akin to the Java spec, that would allow for multimodule components to be developed that would be as easy to use as CPAN modules are today.