I suspect that pg meant to say "should not be exposed BY the class that holds the collection." Then it makes perfect sense.
This was a very nice reminder for me, anyway, of the usefulness of OOP in certain cases. Although I enjoy the freedom, speed, and flexibility of Perl, it doesn't mean that we should not use a little more structure when it's beneficial to do so.
I must admit that OOP is a weakness of mine, but I am diligently working to improve in that area.
pg's meditation was timely for me. Your question helped expose the crux of pg's point. That's why I'm voting for both of your nodes. | [reply] |
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..
| [reply] |
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.
| [reply] |
You realize that you aren't actually changing anything? All you are doing is making the method calls implicit rather then explicit.
| [reply] |