in reply to Modules: Building blocks for the Daft Adventure

Well, it all depends on how you setup your module. If it is just a basic package that is not an object and does not \ use Exporter then you would call it like

RPG::DND::modifer(argument list here);

If you use the Exporter module when creating your module, then you can (optionally) import the function name into the current namespace and just call it is as

modifer(argument list);

If you make RPG::DND an object, you would create an object of that type, something like my $rpg = new RPG::DND;, and then you would call it like


Also, you might want to name it something like getModifer rather than just modifier so it is slightly clearer on what the subroutine does.

Replies are listed 'Best First'.
Re: Re: Modules: Building blocks for the Daft Adventure
by Tiefling (Monk) on Jun 12, 2001 at 15:47 UTC
    Thanks, as ever to the Monks, for the quick answer!

    Now I need to know why would I want to use or not use Exporter. I can't see the advantage of having to write eight more characters every time I call the sub - what are the other pros and cons?

    As for making RPG::DND an object, I'm a little confused now. I had thought I understood objects, but now I'm all at sea again. I thought an object was, or was the target of, a blessed reference. (Apologies if that's not expressed in a canonically clear manner.) What does it mean for a module to be an object?

    As for the name of the sub, the name was chosen to bring readability to the final code. If I'm able to say modifier($strength), it'll make the finished text easier for me to read.

    Hope this helps. Thanks for your advice.

    Tiefling, KLB

    -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d++ s:- a-- C++ UL P++ L++(+) E? W+(++) N+ o? K w+(--) !O M- V? PS+ PE- Y PGP- t+ 5 X+ R+++ tv- b+++ DI++++ D+ G+ e++ h!(-) y +? ------END GEEK CODE BLOCK------
      The reason not to use Exporter would be to easily identify which module contains the body of the subroutine that you are calling. If you create many modules and then export them all into the same namespace it might get confusing about which subroutine belongs with which module. Also, it helps to avoid the case of two modules exporting a subroutine with the same name. Just something to keep in the back of your mind as you develop the code.

      As far as the object goes, I think you have a good grasp of what an object is. For a package to define an object, it must contain a subroutine that returns the blessed reference. This is typically named "new" but it does not have to be.

      I may have caused some confusion by using the terms module and package interchangeably - which they are (for the most part) in my own mind. I am not sure of what the actual difference between the terms is though.