Interesting post. Let me hereby attempt to tackle a few of your questions.

1. Should my module's methods croak, or return error codes when they fail?
   This really depends. Generally It's ok for a module method to die if its life becomes unbearable due to a serious bug etc. To remain consistant, I suggest you stick with Croak.
   
   
2. How much internal error checking is sensible? Some external calls will fail anyway if I pass duff data
   You should always do sanity checks. Check subroutine parameter count and type (scalar/hashref/array/...?) and die on invalid use. However, I remember coming across pieces of code that did too much of this kind of check. So, in the end, you have to keep your sanity checks to a level that is sane ;).
   
   
3. Should I use generic methods that can both get and set, or is a single one each, e.g. $o->debug or $o->set_debug(1); print $o->get_debug?
   No, the way you do it now is great. That's what I'd do anyways ;). In the end, it's always easier to deal with just one method rather than two. Say, why should anyone keep two get_ and set_ methods when a context (lvalue etc.) in which a method is called is clear enough indication what the method should do (either of the two: get or set an object attribute).
   
   
4. If I want to submit it to CPAN, how do I go about it? I know CPAN has instructions, but USENET seems a scary place, and I don't know if the code is worth anything to anyone else?
   I think by posting here you are already one step closer to getting your module on CPAN. Further, you may want to seek some advice on the name space you are using for your package. I believe there are special discussion groups/forums dedicated to just that ;).
   
   
5. What works best, lots of methods to set things, or via the constructor in one go?
   In case of accessor methods, it's good to keep them regardless of whether your constructor is able to accept initial object settings. However, my suggestion would be to allow as much stuff initialized through your constructor method as possible. Otherwise, a user of your module would have to call 100 and 1 methods to properly initialize an instance of your RRS::Tools class before even being able to do any work on it. I suggest you don't make it a necessity by allowing as much (initialization) work to be done through the constructor as possible.
   
   Whew... well, that was my 3.2 cents there.
   
   

   "There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith

   ---

   In reply to Re: Thoughts On Object-Oriented Module Design. Input Sought. by vladb
   in thread Thoughts On Object-Oriented Module Design. Input Sought. by ajt

   Title:
   Use:  <p> text here (a paragraph) </p>
   and:  <code> code here </code>
   to format your post, it's "PerlMonks-approved HTML":
   
   
   
   

   ---

6. Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
7. Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
8. Read Where should I post X? if you're not absolutely sure you're posting in the right place.
9. Please read these before you post! —
   • How do I compose an effective node title?
   • How do I post a question effectively?
   • Markup in the Monastery
10. Posts may use any of the Perl Monks Approved HTML tags:

    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

11. You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

    	For:		Use:
    	&		&
    	<		&lt;
    	>		&gt;
    	[		&#91;
    	]		&#93;

12. Link using PerlMonks shortcuts! What shortcuts can I use for linking?
13. See Writeup Formatting Tips and other pages linked from there for more info.