On Tue, 23 Jan 2001, John Hughes wrote:
> > I had already reached the same conclusion after I saw that
> > everyone would have to remember to say "my Dog $spot;" every time or the
> > whole thing falls apart.
>
> Falls apart? How?
If you forget the "Dog" part somewhere, it's slower than a normal hash.
> > If you want something reasonably close, you could do what a lot of the
> > Template Toolkit code does and use arrays with constants for key
> > names. Here's an example:
>
> Yes but then you get neither compile time (my Dog $spot) nor run time
> (my $spot) error checking.
As Matt pointed out, you get compile time errors if you use an undefined
constant as a key.
You can also do this sort of thing with hashes, like this:
use strict;
my $bar = 'bar'
$foo{$bar};
If you type $foo{$barf} instead, you'll get an error.
> How are you going to debug the times you use a constant defined for
> one structure to index another?
Different classes would be in different packages.
> Oh, do it all through accessor functions. That'll be nice and
> fast won't it.
Well, I thought we were talking about data structures to use for objects.
A few months back, when making design decisions for a big project, I
benchmarked pseudo-hashes on 5.00503. They weren't significantly faster
than hashes, and only 15% smaller. I figured they were only worth the
trouble if we were going to be making thousands of small objects, which is
a bad idea in the first place. So, we opted for programmer efficiency and
code readability and wrote hashes when we meant hashes. Of course, since
this stuff is OO code, we could always go back and change the internal
implementation to pseudo-hashes if it looked like it would help.
If pseudo-hashes work for you, go ahead and use them. If it ain't
broke...
- Perrin
