So, I guess what I really was trying to ask is should the concepts behind the Decorator pattern, when implemented Perl, be implemented with class inheritance or object composition?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

It depends on how you intend to use the classes.

If you want to pass around a single object that can take multiple forms:

    $e = $string->html_encoded();
    $b = $string->base64();
[download]

you can use polymorphic inheritance:

    package My_string;
    @ISA = qw( HTML_decorator  Base64_decorator );
[download]

which is convenient when you know you'll want multiple formats, and are sure you'll know what format you want each time you use the object.

OTOH, if you want to aggregate groups of objects that use different formats, you might want to use composition, and store the decorator instead of the base class:

    for $i (@input_strings) {
        if (&is_plain ($i)) {
            $s = $i;
        } elsif (&is_html ($i)) {
            $s = new HTML_decorator ($i);
        } elsif (&is_CDATA ($i)) {
            $s = new Base64_decorator ($i);
        }
        push @output, $s;
    }
[download]

Then you can use the contents of @output without knowing or caring what format each element happens to be.

.. or not. Patterns give you ideas about what to do without telling you how to do it. If it runs, and it does what you want, it's right. Deciding what you want is up to you.