Re^4: Help understanding object constructors (by Perl Best Practices book)

Not playing nice isn't necessarily a bad thing. However, it is still a reason why I choose to use hash-based objects in most of my programming. The ability to debug w/DD is a very nice thing indeed.

Class::Std is, first off, not thread-safe. Second, if I inherit from Class::Std to create my own OO model based on it and I don't call SUPER in the DESTROY, there's a memory leak. (It's pathologically idiotic, but it's there.)

My benchmark numbers are simple ones from playing with it and what I've seen reported. I will gladly stand corrected given the responses I received.

As for subclassing, Damian has tried to work around the problems when two attributes are declared with the same name in the same hierarchy. But, that's still a problem. While you and I both know that it's a problem inherent to inheritance and composition in general, people cite inside-out objects as a way of avoiding hashkey clashes (which it is), then conclude that it's a way of avoiding attribute clashes (which it isn't). I was merely making that point explicit.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^4: Help understanding object constructors (by Perl Best Practices book)

Replies are listed 'Best First'.
Re^5: Help understanding object constructors (by Perl Best Practices book) by Perl Mouse (Chaplain) on Nov 08, 2005 at 09:50 UTC
Class::Std is, first off, not thread-safe. And I was thinking you were objecting against inside-out objects. Class::Std is one way of doing it - and IMO, not the best way. Second, if I inherit from Class::Std to create my own OO model based on it and I don't call SUPER in the DESTROY, there's a memory leak. Sure, but that's not a Class::Std quirck. If you subclass any class that has a DESTROY function, and you create your own DESTROY function without calling SUPER, you will have a problem. Be it a memory leak or something else. It's an artifact of the way Perls objects are designed (no auto cascading of either DESTROY or AUTOLOAD) - not something unique to inside-out objects, or Class::Std. My benchmark numbers are simple ones from playing with it and what I've seen reported. Feel free to post your benchmarks. As for subclassing, Damian has tried to work around the problems when two attributes are declared with the same name in the same hierarchy. But, that's still a problem. While you and I both know that it's a problem inherent to inheritance and composition in general, people cite inside-out objects as a way of avoiding hashkey clashes (which it is), then conclude that it's a way of avoiding attribute clashes (which it isn't). I've no idea what you mean by this. Could you give an example? `Perl --((8:>*`	[reply]
Re^6: Help understanding object constructors (by Perl Best Practices book) by dragonchild (Archbishop) on Nov 08, 2005 at 13:18 UTC
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]