That some people can do bad things doesn't convince me that I should give up using Data::Dumper on an object without creating an as_dumped_string method in every class.

That's a slightly tangential argument. Using Data::Dumper on an object implies an assumption that an object is its own data structure. That breaks down when the object is merely an index into external data structures, irrespective of whether those external data structures themselves can be dumped.

It's really a paradigm switch from OO programming (objects have behaviors) to imperative programming (functions have arguments) and that only works so long as there's a common practice to write objects that work both ways.

At least Storable has a (somewhat) sensible way of allowing objects to play nice with it. Data::Dumper does not, as I found out in Hooks like Storable for Dumper?.

It's a completely tangential argument, because I think people argue about the wrong things. :)

When people start talking about what Perl should do (or shouldn't do), they forget to think about what they have to give up. Seemingly simple changes have long-reaching consequences, and there are trade-offs. You never just fix one thing. You fix it and break other things. In this case, when you fix the encapsulation issue, you break my whipupitude.

In Perl I don't have to think about your paradigm shift because I don't have to choose. I don't even have to shift. I use what's expedient. That I can mix these in Perl is quite powerful. It works because there already is a common practive to write things both ways. That's always going to work in Perl because an object is just a blessed reference, and most objects I run into are going to be anonymous hashes, despite all the odd things that people could do with their classes.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

most objects I run into are going to be anonymous hashes

That's a convention and it works only so long as people follow the convention. Conventions can change, unlike (or at least faster than) features built into the language.

In this case, when you fix the encapsulation issue, you break my whipupitude.

That's true, but so what? The "whipupitude" (?) was broken to begin with because it assumed that people would only write objects one way. Adding encapsulation just reveals that flaw and, ideally, would prompt some better thinking about "whipupping" in a more diverse way.

I go back to Storable as an example of a module that lets people work in either paradigm and is humble enough not to assume that things will always be done one way. Unfortunately, its way of doing that means implementing a custom hook.

We actually could use a more standard convention in Perl for a transparent structure for objects and built-in types. It would need to be complimented with a standard method name for generating/processing them to be useful in multiple places. That's where a "built-in" feature of the language could help create some standardization.

For example, just as we have stringification, numification, etc., via overloading, perhaps we need "objectification" to a standard format as well.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

You can’t use phrases like “on par” and “inadequate” without also explaining your metric.

I did lay out the metric; that’s what the post was about.

So, who should win?

What I am after will offend some people’s sense of beauty, but works out favourably on all other metrics, near as I can tell. Which is just why I want it.

In my experience, no level of language enforcement stops bugs.

I’m not looking for enforcement – I said as much in the post, right? I want encapsulation to be the default situation, but not the only one. I want to be able to write a subclass without worrying about what any superclass is doing under the covers, because I’m secure in the knowledge that if I don’t go rooting around for anyone’s underwear, I won’t run into it. It’s the same principle as global variables.

Just wait to the dumb kids start using Ruby to see a lot of bad Ruby code.

This the exact point I made in an article on lesscode.org.

I don’t mind that Perl allows people to break encapsulation.

I would mind if it didn’t. (Ruby allows it too, for that matter.)

That some people can do bad things doesn’t convince me that I should give up using Data::Dumper on an object without creating an as_dumped_string method in every class.

Precisely. And more to the point, being able to break encapsulation allows abstractions that are impossible in a language with enforced encapsulation. And that, I really care about. A tool with which you can’t do any damage is worthless.

I’m not asking for strong encapsulation, I am after an OO approach where isolation is the default, so I won’t have to worry about accidentally breaking superclass code, just because I decided to use a private instance variable that happens to be named the same as a private instance variable in one of the superclasses.

Hence “advisory encapsulation.”

Makeshifts last the longest.

By metric, you have to explain how you measure adequacy. You haven't done that. If you meanto imply that adequacy is completely measured by encapsulation then the argument is quite silly.

I'm not arguing with you about encapsulation. I think you missed the point about OO programming by arguing that you can't do it adequately in Perl.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

The metric is: is there a way which keeps my subclass a) isolated and encapsulated from any implementation details of the superclass b) while later letting me break this subclasses’ encapsulation iff I so choose? I explained how the approaches known so far fail to satisfy this metric. (Except I missed the fact that xdg pointed out.)

Ruby offers that, which is why I said Perl 5 is not on par with it. (Turns out it is.)

Makeshifts last the longest.