Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've been trying to maintain some legacy code that badly needs updating. One of the main sins committed in this code is direct object access, so $obj->{attribute} = 'value', rather than $obj->set_attribute('value');

    Is this actually broken? In that, is this direct access causing you sufficient hassles that it's worth the code churn to change it?

    Change means the potential for breakage, and clouds the revision history given by your version control change annotation. There is a great temptation as the

    • Is this actually broken? In that, is this direct access causing you sufficient hassles that it's worth the code churn to change it?

      It's caused a little bit of trouble as some coders have lazily stored values in the objects that shouldn't be there. It took me ages to debug these things (although it's easy now I know about them). If they'd been forced to used accessors the design would have been tweaked and would be much better as a result.

      Anyway, I don't intend to change all the code at once. Instead

      • Instead, any new functionality or any rewrites should use the accessors.

        Is that a requirement specifically for this project, or do you always want this?

        I don't often write accessors. I only write an accessor if I explicitely want to expose an attribute to the outside world. Otherwise, I won't provide an accessor. The problem, IMO, is that there's no such thing as private methods - any method is automatically part of the API. Which means that whenever your removing an attribute that has an accessor fro

        • The problem, IMO, is that there's no such thing as private methods - any method is automatically part of the API.

          I disagree that this is always the case.

          Your API is what you document it to be. It's perfectly valid to either document "private" methods elsewhere, or put them in a part of the documentation that has the disclaimer "The behavior of the following is unspecified. This is how these might work now, these are all subject to change without notice, I guarantee nothing."

          I suspect that you know that, and are instead arguing "In practice, people will use methods as if they were a documented part of the API."

          • by Abigail (26) on 2006.12.07 3:42 (#52130) Journal

            I disagree.

            The problem is just as I said. There are no private methods. Suppose class 'A' defines a method 'foo', and class B inherits A. No matter how often A documents 'foo' to be private, B is robbed from having a method 'foo' and do away with it freely. That's the essense of not having private methods - all methods will be inherited by a subclass. Programmers (can) read the documentation, but perl will not.