"Oh, line comes from another module, so if possible, is there a way to use it as is? I use line in every script I write where I am printing lines."

Sure. I left it out in the interests of self-containedness. But it should just be a case of (in package MyElem):

    sub _line {
        shift;
        my $tab = shift;
        require The::Other::Module;
        The::Other::Module::line($tab, join " ", @_);
    }

[download]
e

"choroba suggested I build the @attributes separately, and I agree. I will be looking at what he did and see how I can modify it to my exact needs then adding it to the module."

Yes, in my final update I did this.

"Also, the last time I tried figuring out OO, I was told I did it all wrong."

Yes, I recall. That's why I took it in stages, so you can see how one style of coding translates to another. If I'd just posted the final version, it might be a bit mysterious how the things in your code corresponds to mine.

Seeing the different steps makes it clearer that I didn't really add or remove much; just structured it into smaller parcels; replaced arrayrefs and hashrefs with objects; and replaced function calls with method calls.

The main thing this buys you is polymorphism: a table object can call the output method on one of the row objects it contains, and it doesn't need to care about what type of row it is.

Polymorphism is the main reason why people bang on about about OO all the time. It's a really great way of maintaining separation of concerns (i.e, so the MyCell package knows all about how to output cells, but the MyRow package needs to know nothing about how to output cells), and providing extensibility. An example of extensibility might be that you could define a new cell class:

{
  package MyCell::Important;
  use base "MyCell";
  sub _init {
    my $self = shift;
    no warnings "uninitialized";
    $self->{style} = "color:red;font-weight:bold;$self->{style}";
  }
}

[download]

And you can use your MyCell::Important class in tables without needing to make any changes to the MyRow or MyTable classes at all!

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

In reply to Re^3: I'm stuck adding more named parameters to a subroutine since the new named parameters might have the same name as the current ones. by tobyink
in thread I'm stuck adding more named parameters to a subroutine since the new named parameters might have the same name as the current ones. by Lady_Aleena

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.