Re^3: OO in Perl 5: still inadequate

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

Comment on Re^3: OO in Perl 5: still inadequate

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]