in reply to Re: Ironclad protection of instance data
in thread Ironclad protection of instance data

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. :)
  • Comment on Re^2: Ironclad protection of instance data

Replies are listed 'Best First'.
Re^3: Ironclad protection of instance data
by CountZero (Bishop) on Jul 04, 2004 at 12:35 UTC
    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