First of all, "inside-out objects" as a name doesn't suggest anything about being standard or not.

This is, unfortunately, a Damian-created issue, with a number of new modules released to CPAN with "::Std" as part of their names, coincident with the release of Perl Best Practices. "Class::Std" should not be read as "Class::Standard" as it's anything but. Pronouncing that suffix letter-by-letter gives a better sense of the caution and prophylaxis that should be considered before using it.

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.

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.

You are completely missing the point of inside-out objects. The point of inside-out object isn't to prevent accessing data. The point of inside-out objects is on the one hand to prevent accidental access of data (collisions), and on the other hand to give you compile time errors when making typos in the attribute names.

Inside-out objects is to OO programming what 'use strict', lexical variables, and name-spaces are to non-OO Perl programming. None of it prevents anyone from getting to anything one wants - but that doesn't mean 'use strict', lexical variables and name-spaces aren't very good ideas.

Perl --((8:>*

"inside-out objects" as a name doesn't suggest anything about being standard

The name is Class::Std, i.e. "Class Standard.

Let me recall what you wrote:

And finally, I don't use them because, despite the name, they are the exact opposite of standard.

That's plural. The thread is named Seeking inside-out object implementations. If your objection is about the name of a single module, then the use of plural is misleading. It would also mean that that objection doesn't hold for different implementations of inside-out objects.

Unless you want to claim that the name of inside-out objects is "Class::Std". In which case you are utterly wrong. "Class::Std" is a way of implementing inside-out objects, not 'the way'. Dismissing inside-out objects based on a single module is like dismissing databases because you don't like MySQL, or dismissing cars because you don't like Fords.

Perl --((8:>*