Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Be more OO with "Class" modules?

by chunlou (Curate)
on Jul 30, 2003 at 22:21 UTC ( #279397=perlquestion: print w/replies, xml ) Need Help??
chunlou has asked for the wisdom of the Perl Monks concerning the following question:

Just wondering if someone should use (extensively) the modules that extend Perl's OO capability.

My feeling is, since they're not quite part of the core, to play safe, I'd rather not include them, even though I like try-catch block and exception handling very much.

What's your thought on that?


Replies are listed 'Best First'.
Re: Be more OO with "Class" modules?
by Abigail-II (Bishop) on Jul 30, 2003 at 22:38 UTC
    My feeling is, since they're not quite part of the core, to play safe, I'd rather not include them

    I think this is one of the silliest reasons not to use a particul module. I guess you'd roll your own database access, and graphics code, because DBI and Tk aren't in the core?

    I think you first should decide which OO style you'd like to use. Perl doesn't give you much on OO, it let's you do all the dirty work, with all its rope to hang yourself. (Perl's attitude towards OO is like C's attitude to memory management: almost non-existent, with deep and dark pits). If you go for the de-facto "standard", the dirty and dangerous grab-bag hashes, there are lots of OO modules that may help you on CPAN.

    Personally, I'd go for a more sound approach, like fly-weight or inside-out objects. I don't think there's much helper modules for those styles out there, but that's, IMO, a small price to pay.


Re: Be more OO with "Class" modules?
by diotalevi (Canon) on Jul 30, 2003 at 22:38 UTC

    What, you don't use other CPAN modules either? This is one of the primary selling points of this language - that it has such a large library. Of course you should use things from the Class:: namespace when they make sense. Similarly, use DBI, DBD:: and anything else from CPAN that helps you write quality software.

Re: Be more OO with "Class" modules?
by shemp (Deacon) on Jul 30, 2003 at 22:48 UTC
    It has been my experience that, even when i need a rather esoteric functionality, there is usually something at CPAN that approximates what i need. If it does what i need, great, if not, maybe i can modify it, or at least get some ideas on how to code my specific need.
    It is quite rare that you need a functional module that no one else has ever concieved of. So, the few minutes it will take to find something on CPAN, download it, install it, and begin learning to use it will surely save you design time to re-invent the wheel.
    Also, there have probably been a number of programmers that have at least reviewed the code, and made some tweaks, so it's generally not realistic that you'll come up with a much better solution. It does happen, but you'll save time in the long run by usually taking the existing module.
    Perhaps this involves a misunderstanding of why things aren't in the core. The core is not a repository for everything solid and useful, its for base functionality. Just because a module is not included in the core in no way labels it as inferior or inefficient, just not part of the core.
Re: Be more OO with "Class" modules?
by chunlou (Curate) on Jul 30, 2003 at 22:47 UTC
      We just talked about this here. You should avoid the try/catch syntax, in my opinion. Exception::Class or Error without the special syntax are both good though.
        "You should avoid the try/catch syntax, in my opinion"

        Could you please explain your reasoning? I'm not disagreeing with you per se, just curious as to why.

Re: Be more OO with "Class" modules?
by chunlou (Curate) on Jul 30, 2003 at 23:15 UTC
    If I use something like Error unilaterally in a project, or if some people write a module in an exception-handling way, the others in a good old Perl-ish way, it marginalizes the collective effectiveness. That's why there's a tendency towards using the common denominator. This is not a functionality issue but a language issue.
      This is not a functionality issue but a language issue.

      It's not a language or a functionality issue. It's a development team issue. In any project it will be best to pick a common error handling mechanism. This is true no matter what language you choose.

      If you have multiple people on a team using different coding styles that's a team problem, not a language problem.

      Beyond that it's not really an issue. It's trivial to wrap code that handles errors via return values so that it throws exceptions (e.g. Fatal). It's trivial to wrap code that throws exceptions to return errors (via eval {}).

      Personally I would recommend using exceptions since I find they have many advantages. However, this is an issue for your development team to decide after weighing the pros and cons.

      Exceptions are also completely separate from OO. You can, if you wish, have an exception handling system with just plain strings (although I wouldn't recommend it).

      The try/catch syntax supplied by Error has some problems as perrin has already pointed out. However this has to do with prototyping/blocks/closures rather than exception handling in Perl. All the other modules do is provide some syntactic sugar for declaring exception classes and throwing exception objects.

      There is nothing special about these classes and objects - they're just normal Perl objects. Exception handling is a core part of Perl and you shouldn't worry about using it if it's appropriate for your project. For many kinds of Perl applications (e.g. DBI) exceptions are really the only way to go.

      If I write tests in a project and other people don't, it marginalizes their and my effectiveness. If you're working with other people on a project, you should have coding standards. This is not a language issue, it's a playing-nicely-with-other-people issue.

        That's a good way to look at it. There could be coding standards if it's a within company project, not when we're taking over a project from someone else. try-catch block like that isn't a most common coding style in Perl.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://279397]
Approved by diotalevi
[1nickt]: \my %foo = { bar => 1 }; say $foo{bar};
[Corion]: 1nickt: Would be great, especially for naming parameters in @_.
[Corion]: When you pass an arrayref, you get to treat it like a local array. But then, I'm cautious with the experimental features, because just when I thought function signatures were a set thing, there is a proposal to use sub [ $foo, $bar ] { ... } to ...
[Corion]: ... declare the parameters, instead of the more common sub ($foo, $bar) { ... }

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2017-11-17 20:40 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (272 votes). Check out past polls.