|
in reply to Re^2: Help understanding object constructors (by Perl Best Practices book)
in thread Help understanding object constructors
They don't play nicely with Data::Dumper or Storable
Yeah, but is that a bad thing? 'Data::Dumper' and 'Storable' only work by making assumptions on how objects are implemented - they assume the entire state can be captured by capturing the content of the referent. Which, in many OO circles, is seen as very bad programming. Not playing nice with someone who isn't playing nice isn't necessarely bad IMO.
They can have memory leaks (even Class::Std can under pathological circumstances)
What circumstances are those?
They are about 10x slower than hash- or array-based objects under average use
Do you have a benchmark? I'm not at all interested in the numbers - what I'd like to see is what you classify as "average use".
Extending the class on the fly is unintuitive
Really? How is extending the class when using inside-out objects any different from non inside-out objects? Or do you mean "I can't get at the data"? That seems to be the point Damian is making in his book, isn't?
Subclassing can still have bad situations
What do you mean by that? What is a "bad situation"?
|
Re^4: Help understanding object constructors (by Perl Best Practices book)
by dragonchild (Archbishop) on Nov 07, 2005 at 17:05 UTC
|
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?
| [reply] |
|
|
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?
| [reply] |
|
|
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] |
|
|
