Re: Using the strict module in object oriented programming

It sounds like you want Tie::Hash::FixedKeys

Update: The above answers the problems that you've described in the example code -- not the title of your question, which are actually two different things:

# accessing an item in a hashref:
$hash->{'key'};

# calling an object method
$object->method;
[download]

Although an object may be a hashref, and the methods may be accessors to the items within the hash, they don't have to be the same thing, and frequently aren't.

Comment on Re: Using the strict module in object oriented programming Download Code

Replies are listed 'Best First'.
Re^2: Using the strict module in object oriented programming by jimt (Chaplain) on Jul 25, 2006 at 14:37 UTC
Admittedly, I haven't looked at this module (or really tied things in general recently), but isn't there always an additional speed hit for using a tied variable? AFAIK, this hasn't been optimized away, but, as I said, I haven't kept up on the subject. Due to the potential for "big" speed hits, I'd look at something like this as merely a stopgap to keep you from shooting yourself in the foot until you've moved over to an accessor/mutator based approach (dealer's choice as to how). Yes, yes, there's also a performance hit from using accessors vs direct hash keys, but it's usually going to be less than the hit you'd get from using a tied hashref. That way you could drop in the tying widget to stop the bleeding now, but you slow down your system slightly. Next step is to get rid of the calls to the keys and replace 'em with accessors. Step 3 is to pull the tied hash back out and get a raise for optimizing the code, conveniently leaving out the part that you slowed it down to begin with. ;-)	[reply]
Re^3: Using the strict module in object oriented programming by jhourcle (Prior) on Jul 25, 2006 at 15:00 UTC
Admittedly, I haven't looked at this module (or really tied things in general recently), but isn't there always an additional speed hit for using a tied variable? Yes. And 'use strict' and 'use warnings' also impose penalties -- you have to look at the situation, and see if the penalties from using something are worth its benefits. Sometimes, it's worth using something in development, and then take it out before it goes into production. Eg, in the examples from the original poster, only constants were used to access the hash, so FixedKeys isn't needed after the program's been written and tested. (if you were using potentially tainted variables as hash keys, you might want to leave it in, but you'd have to look at the costs, benefits and other risk factors for that particular case).	[reply]
Re^4: Using the strict module in object oriented programming by diotalevi (Canon) on Jul 25, 2006 at 20:42 UTC
Comparing compilation of strict.pm and warnings.pm to having to access tied variables is unfair. You are strictly correct that saying `use strict;` isn't zero cost. The first time that is said anywhere in the program, the strict.pm file has to be loaded and compiled. Then everytime `use strict;` is said, `strict->import;` is called once during compilation. Strictly speaking, that's not free. It is, however, as cheap as anything ever gets in perl. It sets two scalar values. That's it. There is no additional runtime overhead. In all terms I've ever come to recognize, strict and warnings are free because any module you load will at some point have loaded it. Tied variables incur all the same costs but they also cost an additional function call for every time the variable is accessed. They also cost a little bit when it comes to magic resolution and a little bit more if your ISA cache isn't up to date. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply] [d/l] [select]
A reply falls below the community's threshold of quality. You may see it by logging in.