in reply to Re: Re: Help with ADT
in thread Help with ADT

Well, you have to poke *somewhere* in your code in your datastructure, otherwise it wouldn't be useful. You can make the most beautiful API, but if you never put something in your datastructure, or never look at something inside it, it's not going to be very useful.

I don't think the post gave any indication the accessing was done outside of an API. Perhaps it was, but there's no reason to assume it so.

Not that whether it was done inside or outside an API has anything to do with his problem.

Abigail

Replies are listed 'Best First'.
Re: Re: Help with ADT
by dragonchild (Archbishop) on Jul 25, 2002 at 14:48 UTC
    Yes, it does. If you're within an object and you're doing 2- and 3-deep lookups into $self, you're programming horribly. It's mean, but true.

    Even within an object, you should be using your accessors. In addition, using objects would allow you to abstract out some of the parts of this ADT. For example, dimmesdale has this concept of a "measurement". That should be abstracted out to some other object. Now, you deal with anything in that measurement through that API. This actually solves his initial problem.

    Plus, I suspect that he's working with test subject data, from the little he posted. There are usually hundreds of measurements for a given test subject. So, he has a List of Measurements within a TestSubject, all with appropriate accessors. The DB-access methods are now a piece of cake. The display methods are a piece of cake.

    I'm not always "OO rulez" or whatever. But, if the shoe fits ...

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

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
      If you're within an object and you're doing 2- and 3-deep lookups into $self, you're programming horribly. It's mean, but true.
      First of all, in the given example, we are not using objects. But that's not really relevant. However, if you consider 2 level deep lookups to be "horrible", then there's an awful lot of horrible code out there. Sometimes a 2 or 3 level deep lookup could be coded better. But dismissing any 2 or 3 level deep lookup as "horrible programming" is just stupid. That would mean you couldn't even access an entry in a two dimensional array without an intervening method lookup. 
          $self -> {$feeble} {$fubble};

      [download]
      isn't in anyway harder to understand than 
          $self -> feeble ($feeble) -> fubble ($fubble);

      [download]
      Except that the latter exposes the method feeble to the outside world and is less efficient.

      Of course, non of your advise would have brought him a micron close to solving his problem. You still can't treat a reference to an array as a reference to a hash, or the other way around, regardless how deep you do your lookups.

      Abigail

[reply]
[d/l]
[select]
        I'm not advocating that all 2- and 3-level deep lookups are bad. If they're within an object, you should be considering to have a has-a relationship going on, abstracting out that complexity. In my eyes, you need to prove that a 3-deep lookup is necessary, within an object. Usually, you're better off abstracting it out.

        If the abstraction takes place, he'll find the reason(s) why he's trying to do what he's doing. It's a design issue, made difficult because he's dealing with too many pieces of information at once.

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

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]

In Section Seekers of Perl Wisdom