On Sat, 4 Oct 2003 14:06:13 -0500, Mark Stosberg wrote:
> On Sat, Oct 04, 2003 at 02:34:14PM -0400, James E Keenan wrote:
>
>>
>> .. that package Drawing is so huge that it's cumbersome to edit
>> and you simply want to store some of its publicly callable
>> methods in other packages. If so, then you could simply import
>> the methods from the "sub"-modules using Exporter.
>>
>>
>> package Drawing;
>> use Drawing::Manipulate qw(Move Copy);
>> use Drawing::Defined;
>> ...
>>
>>
>> package Drawing::Manipulate;
>> use Exporter;
>>[EMAIL PROTECTED] = ("Exporter");
>>[EMAIL PROTECTED] = qw(Move Copy);
>>
>
> While this is certainly more explicit, it also means that every
> time you create or rename a shared routine, you have to declare and
> [sic] at least two places. Perhaps being explicit is it's own reward. I
> know I've found that maintaining export/import interfaces between
> highly related modules to be cumbersome at times.
>
Hmm, I see your point. In part this may be a matter of taste. I tend to think of
inheritance/polymorphism as "sharing code vertically" and non-OO modules (those using
Exporter) as "sharing code horizontally" -- bringing in code "from the side" rather
than "from above or below." I've written both kinds of modules, though my day-to-day
work tends toward OO because it meets the basic OO criterion of "data sets plus rules
for accesssing the data." But often my OO modules themselves pull in code from the
side via Exporter. TMTOWTDI.
Eric's description seems to be more bringing code from the side rather than from
above/below, so that's why I'm inclined to advise an Exporter-approach rather than an
OO. We would probably have to know more about the future scope of his project to make
a better judgment.
