Class::Std is the module most-cited in the last few months as "The Way" to do inside-out objects and the one that was cited in the reply that I castigated. Inside-out objects, as a process, are no more or less threadsafe than any other OO model.
Again, I'm discussing Class::Std because it's the one being discussed. You're right - any time you subclass a module with DESTROY, you have to be sure make sure you call it from within your DESTROY, and the same with AUTOLOAD. I point it out because a lot of people who don't understand that are using Class::Std as if it will cure cancer, and it won't.
I don't have my benchmarks anymore, or I would gladly do so. I also don't feel like rewriting them. I'll let others who actually intend on using Class::Std benchmark it.
Let's say you have an attribute named foo and your accessor is foo(). (Leave aside discussion of mutators vs. separate getters/setters - it makes no difference to this discussion.) Let's say I subclass something that subclasses your class and also provide an attribute named foo(). Whoops!
Now, granted, you are now overriding the presumably published API vs. clobbering an unpublished internal structure as you would be with hash-based objects. But, $self->foo() will now be unable to reach the grandfather's foo(). Thus, the internal workings of the grandfather class may or may not be compromised.
I bring this up because people are pointing to Inside-out objects, and specifically Class::Std, as a way of avoiding hashkey clashes. That's true, but it doesn't solve the problem of accessor clashes, which is the real problem that's, AFAIK, almost intractable.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |