in reply to •Re: "Rites of Passage" wheel reinventing
in thread "Rites of Passage" wheel reinventing

I'm curious - why would you consider a class wrapper to autogenerate accessors to always be a bad idea? I've got on working on my production site that I've been tinkering with for over 3 years and it's actually improved our development time and reduced complexity.

The example I can think of is that we have a number of reports which are similar in structure. They all take a set of parameters that are a subset of all parameters. Which parameters are report-dependent, but they all need to be handled similarly. So, the report class will say "I'm using these parameters" and the parameter class will add the appropriate attribute(s) to the report class.

Parameters are broken out because they also:

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

  • Comment on Re: •Re: "Rites of Passage" wheel reinventing

Replies are listed 'Best First'.
Re^3: "Rites of Passage" wheel reinventing
by hardburn (Abbot) on Feb 27, 2004 at 14:36 UTC

    why would you consider a class wrapper to autogenerate accessors to always be a bad idea?

    They tend to encourage people to spread accessors everywhere throughout their classes and use them as a crutch for a broken design. Autogenerating mutators are even worse, because now you're not just grabbing internal data, but modifying it, too. You might as well be passing around a bare hash reference and tell everyone to do what they want with it.

    Accessors (and to a lesser extent, mutators) can be used well, but they shouldn't be everywhere.

    In fact, I'm starting to wonder if Class::DBI was actually a step backwards over Ima::DBI, which Class::DBI is based on. The reason is that Class::DBI exposes the entire database layout, while Ima::DBI performs some action based on the database using pre-defined SQL. I haven't come to a firm conclusion, though, and certainly many people have used Class::DBI to great success.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      Regarding Class::DBI, I guess it depends on whether you believe that the module is providing object persistence, or transparent access to SQL-based records. If the latter, the current scheme makes perfect sense: you want your objects to have accessors for every column. If the former, then it's definltely broken for the same reason I made my comment up the thread. And most people seem to be using it for the latter, so that's why it's so successful. {grin}

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

[reply]

      One big advantage of accessors over passing round a hash is that if you mis-type an accessor name you get an error about an unknown method whereas if you mis-type a hash key you get a bug that may be hard to diagnose.

[reply]

        That's an advantage in Perl5, yes, but good class design is language-agnostic. There might be a language which provides locked keys for hashes by default, or perhaps you use one of the locked keys implementations in Perl (using a tied interface). Or maybe your language doesn't have hashes, but it has structs which are statically typed and serve the same purpose, and thus a compile-time error is generated anyway.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]

In Section Meditations