On Sat, Jan 05, 2002 at 07:31:27AM -0800, Randal L. Schwartz wrote: > >>>>> "Tim" == Tim Bunce <[EMAIL PROTECTED]> writes: > > >> Your name space point is a valid one. DBI solves this by tying the hash > >> and only allowing new keys to be added if prefixed with 'private_'. > > Tim> And I'll be tightening up the docs for that to make specific > Tim> recomendations for subclasses to use 'private_<classname>_*'. > > The problem with encouraging subclassing by documenting it is that you > are forever locked in to using a hashref, and thus cannot switch to an > arrayref in the future should you decided to do that for space or > speed.
The DBI's other attributes already tie [cough] us into using a hashref. > If people want per-DBI-handle data, why not provide the data via > $dbh->private instead, which returns a hashref unique to the handle? And shared by all other classes/code which wants to use per-handle data. Doesn't seem to be much of a win. Though it crosses my mind that a $h->private(__PACKAGE__, 'foo') interface would at least force people to consider namespace polution/protection. > Then I can stash stuff there, including behavior using coderefs, > without interfering with the type or operation of $dbh->OtherMethods ? Tim.
