in reply to Ironclad protection of instance data

For the first time, I am going to enforce strict OO standards ...

When I hear this, I cringe. Nine times out of ten, the result will be barely usable, usually because the author's vision for their precious class library hasn't been broad enough to encompass the variety of problems that people might use the class library to solve, and sometimes because the resulting class library is too constrained. (Consider the standard Java classes. Need to extend String? Sorry, out of luck.)

Before you go too far down the "enforce" road, consider the "enable" road. It's a friendlier road, even if it can be a bit more chaotic. If you prefer to stick with the former path, consider switching to a language that supports enforcement with less convolution than Perl requires. Or treat the whole thing as an experiment.

  • Comment on Re: Ironclad protection of instance data

Replies are listed 'Best First'.
Re^2: Ironclad protection of instance data
by friedo (Prior) on Jul 03, 2004 at 18:39 UTC
    Well, the reason I'm doing this is to ensure that subclassing will work painlessly. A subclass will automatically inherrit the accessors for the class data, and some of my instance accessors are somewhat complex, and so I want to ensure that even the objects themselves retrieve data via the accessors rather than directly. If the accessor logic changes, then any method that does direct access may break. These classes are being written by a number of developers which is why I want to ensure that data can't be accessed directly, by accident or otherwise. :)
      This is exactly what Larry Wall warned against when he said in the Llama book on p. 339: "Enforced privacy tends to get in the way of people trying to get their jobs done. Perl's philosophy is that it's better to encapsulate one's data with a sign that says IN CASE OF FIRE BREAK GLASS. You should respect such encapsulation when possible, but still have an easy access to the contents in an emergency situation, like for debugging."

      Still, if you really want to tie everyting down, have a look at pages 339-346 of the Llama book.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law