Re: Anti-inside-out-object-ism

[xdg]

Another common concern raised is about speed.

There is overhead associated with DESTROY that doesn't exist (in quite the same way) for hash-based objects where garbage collection is left to Perl rather than done by hand. If lots of objects are being generated and destroyed, this may be an issue for some individuals.

Also, depending on the implementation, inside-out accessors can be much slower than hash-based accessors, but the difference can be very small if the inside-out class caches the refaddr, as this node demonstrates. (The array-based implementation of Object::InsideOut is faster yet, I believe, but that isn't an apples-to-apples comparison.)

As a side note, the tendency of inside-out classes to be implemented with attributes for syntactic sugar is another potential downside. (Incompatibility with other Attribute::Handlers modules, for example.) But that relates to implementation choices, not the inside-out paradigm itself.

[adrianh]

There is overhead associated with DESTROY that doesn't exist (in quite the same way) for hash-based objects where garbage collection is left to Perl rather than done by hand. If lots of objects are being generated and destroyed, this may be an issue for some individuals.

Although when I've benchmarked inside-out vs hash based versions of objects in real world scenarios the overhead of the extra DESTROY just disappears in the noise.

I suspect it's going to be a rare environment where one extra method call perl object makes a significant difference.