Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Perl Modules

by Sinistral (Monsignor)
on Jun 20, 2017 at 16:05 UTC ( #1193158=note: print w/replies, xml ) Need Help??


in reply to Perl Modules

You might also very much like to read the free e-book Modern Perl which contains a section on modules. You can purchase a hard copy as well, if that is your preference.

Replies are listed 'Best First'.
Re^2: Perl Modules
by jamroll (Beadle) on Jun 20, 2017 at 20:27 UTC
    i'm not opposed to books. they are great. i've read many. the one you suggest is not one i have read. so ... i will check it out. most folks generally point me in the direction of the tutorials and documents one can easily find. but, none address the issue i'm having. most just talk about one module, and not many that interact together and require each other in circus - sometimes two modules need each other in order to do their job. i think this is the underlying problem i'm having, but i can't be 100% certain. mainly because I lack a group of friends whom i can have a face to face conversation with. one man band kinda sucks, but i'm determined to get this site up and going!
      hello jamroll,

      your thread is long and somehow confusing, but here you say something that captured my attention:

      > many that interact together and require each other in circus

      First some firm stone, to not let confusion overhelm us: Some::Module must be in Some/Module.pm and this path must be in @INC or added to it at runtime using -I perl switch. See perlmod (and perlrun for the perl switch). Also notice that you (i think is not a constrain but more a convention) you start Some::Module declaring a package with the same name package Some::Module; ( PS read tobyink's wise advices in Re: Module's name and file's name )

      Second: the easy way is to use Exporter; and fill @EXPORT_OK with every sub you want to be usable (with use ..) by other programs or modules. All sub you put in @EXPORT will be exported by default, generally not what you want.

      After this basic level abstraction will be the keyword. I have a little experience but when I ended with a tools.pm module as a an unorderd collection of subs i know i was on the looser path.

      For such reason choosing rigth names(spaces) for your modules is so hard, generally harder than choosing sub names. They reflect how you approached the problem/subject you'll resolve with you programs. In more complex cases you can have entire trees of modules with the deeper ones specializing the parent: like Project::Display will be responsable to compose messages to be shown and Project::Display::Console and Project::Display::HTML will handle differnt display types.

      Nothing bad if Project::Logger uses a facility sub you defined in Project::Display .If you are always sure where you put your subs and you export the sub correctly everybody is happy.

      Once a wise programmer said "progrimming is a matter of interfaces" and is true. A lot true. If your module just exposes a mixed collection of beahviours this will no matter a lot. But when you find that some subs in your module are, and possibly must remain, private to such module, you are implicitly thinking an interface.

      Consider having a Project::Postman that is used to send out mails: the module can just expose one or few subs but can have dozen of private subs to check mail addresses, availability of smtp servers.. Less you expose and as much as this remain stable, more you will be able to change internally Project::Postman without braking any program that uses, consumes your module.

      More you stress this in your programs more you tend to just expose one sigle sub that return a scalar, or an object if you want, that is autosufficient and knows who it is and what behaviour to put in the field.

      As much will be easy for you to do such name/functionality abstraction, as much you'll be closer to Object Oriented programming, easy to realize using Perl, with or without OO frameworks.

      As always you have a lot of different options you must follow your inclination or needs of particular projects.

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
        i thoroughly enjoyed that read! :D you got it bang on! thank you for taking the time to help me on this issue. your reply answered a few questions, yes! that was most useful, uh huh.

        so...if i have project::display and project::display::html....how does html use the methods/subs within display? are they inherited into html automagically? blarg! i'm confusing myself...but, do you get what i'm asking? this is why i posted this question as i did, because I haven't a clue what i'm asking, but i need to know it in the worst way lol

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1193158]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2020-05-27 23:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If programming languages were movie genres, Perl would be:















    Results (162 votes). Check out past polls.

    Notices?