Re^2: OO in Perl 5: still inadequate

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?.

-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.

Comment on Re^2: OO in Perl 5: still inadequate Select or Download Code

Replies are listed 'Best First'.
Re^3: OO in Perl 5: still inadequate by brian_d_foy (Abbot) on Jan 21, 2006 at 17:17 UTC
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	[reply]
Re^4: OO in Perl 5: still inadequate by xdg (Monsignor) on Jan 21, 2006 at 19:30 UTC
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.	[reply] [d/l]