Interesting post. Let me hereby attempt to tackle a few of your questions.
-
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.
- 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 ;).
- 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).
- 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 ;).
- 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
|
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
