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

      • by Abigail (26) on 2006.12.06 10:22 (#52116) Journal

        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 from your implementation, your API changes in an non-backwards compatible way.

        Which is why I usually don't use accessors, but use the attributes directly. But since I'm using Inside-Out Objects, I cannot have the problem of willy-nilly added attributes - they all have to be declared in the class.

        • 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."

          • 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.

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

          It's for this project. There are good reasons why accessors are needed for the project.

          However, generally I'm lazy and can't be bothered with any sort of accessors. And in small projects direct access hasn't created any problems.

          When I first heard about inside-out objects, I thought they were solving problems that hardly ever arose. I've become a convert though!