in reply to When are packages the right design choice?

I run into a similar question. I use a hash to store variables used by a group of subroutines, and pass around a pointer to the hash instead of using argument lists. I create modules, so that the subroutines using this pointer are in a module.

My training (from Conway) tells me that this is object-oriented code. The question I run into is, "When should I bless a hash pointer to make Real Perl OOTM code?"

My answer is, "As soon as the API that I want to create benefits from it."

It's all about the interface. I imagine that my subroutine calls look good, and are nicely documented with POD. The synopsis section of the POD is a working program that easily solves a real problem. The calls are easy-to-read and self-documenting.

The bless statement makes it possible to create a better API under some circumstances. If I'm not going to make a good API, I don't bother with the trappings of OO.

If I can imagine a good API, then it is worthwhile to fulfill my vision and implement it with the tools that are available. When I write this code, I often need a bless statement.

Without the vision of a good API, the rules of thumb for "when to use OO" do not inspire me enough to bless my objects. I save my blessings for objects that I want to be proud of!

It should work perfectly the first time! - toma
  • Comment on Re: When are packages the right design choice?

Replies are listed 'Best First'.
Re^2: When are packages the right design choice?
by hardburn (Abbot) on Jun 04, 2004 at 12:45 UTC

    pass around a pointer to the hash instead of using argument lists

    Err, you mean a reference to a hash. Perl doesn't have pointers.

    "When should I bless a hash pointer to make Real Perl OOTM code?"

    IMHO, you should just bless the sucker and be done with it. In the simple case, the worst that can happen is that you move the first argument to the left side of the sub's name (and it'll be a little slower, but that probably won't matter). But if you don't bless, you will have a much harder time getting inheirtance and polymorphism to work.

    There are many "trivial OO" systems, but they often break down under anything more than a trivial class heirachracy.

    ----
    send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.