|
in reply to Re: Help understanding object constructors (by Perl Best Practices book)
in thread Help understanding object constructors
I --'ed your node because it was completely off-topic. The confusion was hash-references vs. loops, not OO constructors. As the OP was confused about basic syntax, bringing up inside-out objects was a bit too much.
Furthermore, inside-out objects is most certainly not the "best way". In fact, many top Perl programmers choose to NOT use Inside-out objects, for a variety of reasons. These would include:
- They don't play nicely with Data::Dumper or Storable
- They can have memory leaks (even Class::Std can under pathological circumstances)
- They are about 10x slower than hash- or array-based objects under average use
- Extending the class on the fly is unintuitive
- Subclassing can still have bad situations (method-based vs. hashkey-based)
They are nice, but they're not the cure for cancer.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
|
Re^3: Help understanding object constructors (by Perl Best Practices book)
by adrianh (Chancellor) on Nov 07, 2005 at 15:04 UTC
|
They are about 10x slower than hash- or array-based objects under average use
Agree with everything apart from this one, which doesn't match my experiences at all.
My inside out classes are within a gnat's whisker of being as fast as plain hash-based objects wherever I've used them, and the slowest inside-out object framework that I've come across (Class::Std) is only a bit over twice as slow when I've benchmarked it.
| [reply] |
Re^3: Help understanding object constructors (by Perl Best Practices book)
by Aristotle (Chancellor) on Nov 07, 2005 at 15:16 UTC
|
- They don’t play nicely with Data::Dumper or Storable
That merely requires that someone write STORABLE_freeze and STORABLE_thaw methods for inside-out objects, and that they make use of Data::Dumper’s Freezer/Toaster stuff (which, unfortunately, is not as automatic as Storable’s hooks are).
None of the problems are insurmountable.
Inside-out objects are not the cure for cancer, but they sure help with gray hairs.
Makeshifts last the longest.
| [reply] |
Re^3: Help understanding object constructors (by Perl Best Practices book)
by Perl Mouse (Chaplain) on Nov 07, 2005 at 15:18 UTC
|
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"?
| [reply] |
|
|
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] |
|
|
|
|
