Welcome to the Monastery | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If Class::Std or "some of the others" interfere with some other tool, why do you blame Class::Std and some of the others, and not the other tool?
Have you looked at how Class::Std is implemented? It's pretty crazy. It includes some "worst practices" too, like use of the UNIVERSAL:: namespace. "inside-out objects" as a name doesn't suggest anything about being standard The name is Class::Std, i.e. "Class Standard." we'd still be using the indirect object notation, because that's how we used to teach programmers in the literature. Views change over time, and documentation isn't static. If Class::Std ever became a very common way to do things, to the point where the Perl man pages used it in their OO examples, I would drop this objection. I think the difference between Class::Std and normal OO perl is a lot bigger than these other examples you gave though. we'd still be using the indirect object notation, because that's how we used to teach programmers in the literature. Views change over time, and documentation isn't static. You're misunderstanding me. What I'm saying is that any attempt to enforce encapsulation is ultimately futile when the other person has the source and can simply change your code to expose things that they want. I will grant that it's much harder to do than it is with simple hash-based objects though. UPDATE: Class::Std does not actually put things in UNIVERSAL::. This technique is suggested in the inside-out objects section of the PBP book, but not used in Class::Std. In reply to Re^3: Seeking inside-out object implementations
by perrin
|
|