And here we see why phrases like "medium-sized" are not very informative. Your concept of "medium-sized" is off by an order of magnitude from what I think is customary in the Perl world.

As for AUTOLOAD, I still disagree. I agree with you that the interfaces should be consistent and the implementations reasonably so. I agree that a standardized implementation helps with that. But AUTOLOADs at key places can still be of great assistance. For instance suppose you need an improvement in startup time. Why not use AutoLoader? If your usage pattern means that any given user only uses a small subset of your total application, the boost could be substantial.

Is that choice going to be unmaintainable? I don't think so! It shouldn't be scattered everywhere. But think of it as being a templating tool. You have templates all over. Somewhere you have code that processes templates and autogenerates code. Would writing custom autogeneration of code everywhere be a horrible idea? Of course! But is having it used in a key way in a key place in your process invaluable? Of course!

Ditto for AUTOLOAD. Think of it as a way to do lazy run-time templates. Useful. Easily abused, but also powerful when used in a controlled, appropriate manner.

As for your specific question, what I didn't like was seeing the use of functions named by fully qualified package name. If you are doing that everywhere, that is a sign of a problem. If it is limited to things that internally should know each other, that is a different question altogether.

As for exporting, all automatic exports in Perl are done with an import method. The usual semantics you see on CPAN are obtained by inheriting from Exporter. If you want to define your own custom import method, that is easy but I would think twice about having a radically different API. An example is at AbstractClass. (It has an import method that writes an import method into the calling class.) Another approach which might fit better into your system is to have a generic import method (something like Exporter has) but have the list of things you are willing to reexport add the things you imported. That allows for an "inheritance" of a functional interface through classes that will play well with multiple-inheritance though not (ironically enough) with AUTOLOAD.

In reply to Re (tilly) 4: Perl and Objects, how do you resolve the two? by tilly
in thread Perl and Objects, how do you resolve the two? by frankus

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.