footpad, in the case of the Windows API, you suggest selective use of the library's features. But unless you are writing your own interfaces to access the internals, you're still playing by the rules. I would wager that you still have to use the interfaces to get at the internal data, but you do so in unique ways in which the developer didn't imagine. That's the job of a developer. Provide all the methods that are necessary to get to the needed information, but as the developer you can never know how this is going to be used. This is the human side of encapsulation, often seen in the situation where the manager hands you a ream of paper and says, "Do this." You just do it, without knowing who's going to do what with it. Of course, this is an extreme model, but it happens.

My big point is that unlike a real OO language (touchy subject I know, but in a comparative sense), Perl doesn't hold these restrictions over our head when it's running a script. We have to take charge and hold these restrictions on ourselves if we choose to develop with a certain API.

tilly may have pointed out the best reason why, even though it's unlikely that certain actions (such as our lovely RaiseError producing warnings) will change, we can't assume that they won't.

ALL HAIL BRAK!!!