|
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.
Abigail
| [reply] |
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.
| [reply] |
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.
| [reply] |
Re: Be more OO with "Class" modules?
by chunlou (Curate) on Jul 30, 2003 at 22:47 UTC
|
| [reply] |
|
|
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.
| [reply] |
|
|
| [reply] |
|
|
|
|
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. | [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
