in reply to Re: multi-tier collections & lack of modulization/OO
in thread multi-tier collections & lack of modulization/OO

Many data structures have very specific rules. Say you wanted to create your own queue. You'd create an array, and do shift's and pushes. But imagine if some dork decide to access or worse, take out the middle item.

Yeah, it's stupid of the developer to do that, but you don't enforce rules on the data.

Let's say you were working on an array, and you have a function returnAverage. One optimizatio you could do, is recalculate the average as you are adding stuff to this array, keeping track of how many elements there are. You wouldn't have to add up all the #'s and divide. You could keep track of the current average, multiply by the current number of items to find the total to create your new average. This is especially true if your array is 100,000,000 elements big.

But imagine if someone directly adds data w/o updating the statistics. Then you have to add all those numbers since they didn't update the statistics. Imagine it like rebuildinga db index. By encapsulation, you can guarantee that your data is accessed in certain ways and things are done in a certain manner.


Play that funky music white boy..
  • Comment on Re: Re: multi-tier collections & lack of modulization/OO

Replies are listed 'Best First'.
Re: Re: Re: multi-tier collections & lack of modulization/OO
by davido (Cardinal) on Dec 12, 2003 at 05:13 UTC
    Of course there is always more than one way to do things. If I were to implement an array of which I always mantained a statistical average of the values of its elements, I might consider tieing the array to a module that overloads the STORE function (and all other applicable to the situation) so that any time a new value is added by any means, the statistical average attribute is updated.

    The attributes could then be obtained via access to the object's methods. ...perhaps a "getstat()" method which would return a reference to a hash of stats.

    Such an approach would guarantee that the stats are always accurate, as there would be essentially no way to modify the array without the stats being recalculated. Performance would suffer a bit, but accuracy would be guaranteed. By using a tied array, the user could do whatever the hell he wants, directly to the array, and an accurate stat. would still be maintained.

    :) Just a thought. And of course, it came to me because I've been playing with tied variables the past few days. Seems like a cool solution though.


    Dave

[reply]
      You realize that you aren't actually changing anything? All you are doing is making the method calls implicit rather then explicit.
[reply]
        Yes, I realize that.

        The example given was using object methods as an interface to an object that encapsulated an array with a statistical attribute.

        My point was that, for the programmer using this module, it might be more familiar ground for the object to look and feel (from the outside) just like a plain old array. In my example, there isn't a new API to learn. And code using the object will look and feel pretty basic. A Perl programmer plays with arrays all the time. We're all pretty much used to the "interface" to arrays. In this case, the simple (for the programmer utilizing the module) approach is to carry that idiom forward seemlessly, or transparently for simplicity's sake. The only thing to learn would be what object method to use in accessing the array's statistical attribute.

        Yes, nothing has really changed internally. But externally, the module's user only has to remember how to play with an array.

        But this is all a big tangent on the OP's thread. I have to agree with the OP that the complexities of a datastructure are often better dealt with through layers of objects. However, I don't entirely agree. The objects should be used to simplify life, not to make it more intricate. Occasionally a complex data structure provides simplification rather than undue difficulty. It's not always bad to let the cat out of the bag.


        Dave

[reply]

In Section Meditations