http://qs321.pair.com?node_id=277317


in reply to Re: USE or Require?
in thread USE or Require?

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 :-) ?

Replies are listed 'Best First'.
Re: Re^2: USE or Require?
by demerphq (Chancellor) on Jul 24, 2003 at 01:20 UTC

    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... :-)


    ---
    demerphq

    <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 :-)

        Well you could have a grab bag of useful methods and approaches all in a single module, and mix and pick as you like. Wheras if you did it via ISA its all or none.


        ---
        demerphq

        <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
Re: Re^2: USE or Require?
by l2kashe (Deacon) on Jul 24, 2003 at 13:58 UTC

    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?

        exporting new isn't useful. Its there more to say to the user of the module, this is the way in. I'm in the camp that doesn't like namespace pollution, so I try to push my bias along to the next person. Either A) they will instantiate via the constructor, or B) they will have to fully qualify all calls via Package::Name::function

        They will either use my module or not. Generally I encapsulate as much functionality as is reasonable in the module. I don't go overboard and include everything, unless its really needed (generally it isn't). The scope of the modules are also pretty closely tied to particular applications used on the network.

        Im not quite sure why people aren't happy with my opinion on the topic. I find code written $obj->method(args) far cleaner, than trying to guess where the function or method is coming from. Since this is the case, part of my best practices is doing use Blah (); unless I simply can't (File::Find and Carp come to mind). My reasoning for only putting new in export_ok, is to simply let people know that the only thing that can be imported, if they want anything at all is the new method and since its in export_ok and not export they have to ask for it explicitly (which generally won't happen). I don't go in for the "shotgun to keep people out of the livingroom" mentality. I only document the public API. I tend to not do class inheritance. If I need functionality from multiple packages, then I encapsulate within my object in the constructor. (i.e $obj->{'socket'} = IO::Socket::INET->new()).

        demerphq's thoughts are interesting, but my reasoning is much more shallow. If anything gets imported from a module of mine, then it won't overwrite anything in the end user's namespace. plain as that. It might not be the best mentality, nor the most technically sound reasoning, but my code looks consistant across the board (both in the scripts themselves and the modules I've written here), which makes it much easier for myself to maintain. On top of that the next person who comes along will be able to readily pick my style out, learn my idiosyncracies fairly quickly, and know what to expect in modules and scripts.

        I wouldn't mind some feedback on what people's reasons are for not liking my view, as I'm trying to become slightly more refined in what I say. I have no "traditional" edjucation in computing or programming, but I've been at this since '99 and feel I have a solid background. Though hanging around the monastary has helped refine the way I frame my thoughts, I still feel like an outsider in terms of the appropriate lingo/vocabulary sometimes. I tend to be able to follow and use new concepts fairly easily. What I don't do well is communicate via text (voice Im slightly better at). So whats the beef?

        use perl;