Largely due to the fact that 99% of the time a hash makes the most sense.
No. 99% of the time, the ease of using a hash instead of a module that will provide OO representation for you overrides the benefits of not using a hash.
A hash is, in nearly every case, the least efficient way of representing an object. Much better is to use an array. (This, by the way, is why pseudo-hashes were created in 5.6 - the attempt to marry hashes and arrays.) Even better (from a space perspective) is to use one array for your entire class (if this is possible). But, you have to both have a baseclass that would represent this and the ability to hand this kind of book-keeping over to another module.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
I don't recall saying it was efficient. It just makes sense as you pointed out:
the ease of using a hash instead of a module that will provide OO representation for you overrides the benefits of not using a hash so.... Yes, right?
How one arrives at such a conclusion is not really important.
I read that "all objects from an array" in one of O'Reilly's advanced perl books too. Having looked at the code required to maintain objects as arrays and the inability to play nicely with serialization tools like Data::Dumper was a real turn off.
Besides, I think the post below referencing the "stash" is probably more correct that anything thus far.
| [reply] |
When I said ease, I should've said "ease of laziness" or "ease of not bothering". Personally, I hate using hashes as OO representations, at least directly. I don't want to think about how my object is represented in memory. Not using an OO-rep module forces me to do my own representation management. To me, that's very un-Perlish.
I guess the sarcasm didn't come through in my first post. I apologize for any misunderstanding.
Yes, the all-objects-in-array in the Panther book sucks with serialization. (The fix is actually relatively simple.)
The other issue, however, is a straw man. You don't worry about the code required to maintain a CGI::Application or a DBI connection, do you? A well-tested CPAN module means you don't have to maintain the code. In fact, you don't know or care what code is required to do something, so long as it does it.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.
| [reply] |
| [reply] |
Warning: I am an expert in neither perl internals or perl threads - so this explanation may be wrong :-)
I think that "stash" in this context is referring to the package symbol table (called a stash in the perl internals). Blessed references contain a pointer to the stash of the package they are blessed into.
From the threads doc I am assuming that this is copied when an object is returned - when it would be more appropriate to use the the package's existing symbol table (if one exists).
| [reply] |