PerlingTheUK has asked for the wisdom of the Perl Monks concerning the following question:
Dearest Monks,
I am trying to get some more common sense to a class, instance of TK MainWindow that I have taken over the maintenance of. Downside is this class has more than 3000! lines of code and wildely assigns key value pairs to its own blessed hash. Some of these are actually accessed or created (exclusively) outside the actual class.
Okay enough description of the desaster. How do I sort this. My so far best guess was to lock keys using Hash::Util and create the following code for actually used hash keys:
This works fine. I have used it successfully for the last 2 days and reduced the number of required non Tk keys to about half their original number plus know what is going on. However in come cases I still discover new keys which are created only when certain expections are thrown or errors occur and depend on the used input data or user interaction. I would therefore like to create a hash wrapper that preferably reports the "caller" and the key whenever a key is added or deleted. In a few weeks I would look at a log file and dive into investigation of those last remnants of 'really really really' bad code. Can anyone point me to a place where I can see how to do this?use Hash::Util qw/lock_keys/; my $self = $classname->SUPER::new( %options ); # Tk keys ||= in order to not overwrite already initialized keys $self->{ _ClassInit_ } ||= undef; $self->{ _Destroy } ||= undef; $self->{ _names_ } ||= undef; $self->{ _TkValue_ } ||= undef; $self->{ _XEvent_ } ||= undef; $self->{ __Images__ } ||= undef; # Local elements - those have not been defined yet $self->{ MyKey1 } = undef; $self->{ MyKey2 } = undef; lock_keys( %{ $self } );
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Monitoring a Blessed Hash
by jdporter (Paladin) on Feb 15, 2006 at 20:13 UTC | |
|
Re: Monitoring a Blessed Hash
by dragonchild (Archbishop) on Feb 15, 2006 at 20:04 UTC |