|The stupid question is the question not asked|
Re: Perl Objects, Internal Representation -- How??by jimt (Chaplain)
|on Sep 15, 2006 at 13:14 UTC||Need Help??|
Boy, this is a huge can of worms. The short answer is "Your mileage may vary."
Perl, in one of the finest (I think) examples of giving you ridiculous power and then forcing you to deal with it allows any arbitrary reference to be an object. So scalarrefs, coderefs, arrayrefs, hashrefs, globrefs, whatever. All sorts of fancy things. But, it's up to you, the programmer, to determine what data is stored where and how much.
Each object is self contained. So, for the simple example of a hashref, it behaves like a normal hashref. If you've set a key in a particular object, then the key & value are stored in that object. They don't appear in any other object. Keys that you haven't set don't appear. Note - I don't know enough about the internals to know if perl does things like optimize constant strings "some_key" so they only appear once in memory. One of the more low level guys may be able to comment.
Methods are usually not stored on a per object basis, but they can be if you want to (using closures or simple coderefs, for example). Typically, they're defined once in the class and all objects of the class (or subclasses!) just point to that one method. But if you want to hang the method off your object, you can. This is something I'd file under "Do it if you need it and know what you're doing."
Arrays have trickier memory requirements, since Perl's arrays aren't sparse (unless they've changed out from under and I missed the announcement). So if you have 100 "slots" in your array-based object, and populate slots 1 & 100, then slots 2-99 are allocated as well (in some capacity, again, I don't know the details of the internals). Note that they're empty, but the slots are still there. I wrote up some other issues over at Problems I've had with array based objects.
And then there are hipper newer things, like inside out objects, which use scalarrefs to key into internal hash tables in the class to store the attributes. So each object has a scalar ref as the object itself, but all sorts of additional data stored in the class level hashes.
I guess you can just remember that if you stick it in the object, it's stored in the object. If you don't, it's not. But the devil's in the details.