in reply to USE or Require?

On the flip side, the only routine I export is new, and that goes in EXPORT_OK. I tend to shy away from writing libs, in a non OOP style. I hate namespace corruption, and I simply don't want to afflict it on the next person in line. With that said I try to do use module (); when I remember. I almost never directly access stuff outside of main's namespace, the only exception I can think of is File::Find, which irks me to no end everytime I use it, but *shrug*

use perl;

Replies are listed 'Best First'.
Re^2: USE or Require?
by adrianh (Chancellor) on Jul 23, 2003 at 20:02 UTC
    On the flip side, the only routine I export is new, and that goes in EXPORT_OK.

    Why on earth would you want to export new in OO code (he asks curiously :-) ?

      Why on earth would you want to export new in OO code

      I struggled with this one for a while myself, wondering what the idea might be, and I have come to a hypothesis, however shaky. :-) If we want to use a common class framework amongst many classes but dont want them to have a common ISA ancestor then we might make a module like

      package ObjectPrototype; use base qw/Exporter/; @EXPORT=qw(new); sub new { my $class=shift; bless {@_},$class }

      so now we can say

      package Foo; use ObjectPrototype; package Bar; use ObjectPrototype;

      without establishing an ISA relationship between any of the module/classes involved.

      I admit however that the only reason I could think that this would be useful is if you were doing some funky by hand @ISA tree walking in your code. Having only done this once myself I dont see it being needed much. Although now the thought has come to me... :-)


      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

        I can't see how it would be very useful since none of the other methods in ObjectPrototype would be available to Foo and Bar :-)

      I attempt to maintain a consistant paradigm. If I need to use the functionality from another module, I instantiate an object and use the defined API. If I need a series of objects, I instantiate them in my constructor and store them in my constructor. I guess only exporting new which is kind of redundant anyway, is bascially stating "Here is the way I would like you to come in, see that API over there, that's for you". If people end up editing the source to export more, or set up inheritance, more power to them.

      Granted it's not the only way to do it by any means, and I give up some functionality, but I prefer the consistancy in all my code produced for this company. In my current position, each module produced is pretty close to the bottom of the food chain. I think if I were providing slightly more generic modules the case may be different, but in the present situation its not necessarily the best solution.

      use perl;

        Sorry - don't understand :-) Could you show some code that shows how exporting new() is useful?