Perl's Built-In OO

There appear to be a few experienced Perl devs who still insist that there's nothing wrong with Perl's built-in object-oriented programming. You bless a reference and do everything manually. Stealing from twitter user @kaesees, I can now explain their opinion in two words: Stockholm Syndrome.


I have no problem with a extendable/optional OO system. But a default or "blessed" by core developer OO system would make me feel easier.

Well, at least that behavior is still with us.

As long as people rather throw witty remarks around instead of thinking about why their opponents have their opinion we'll never reach a consensus.

I love Moose and modern Perl. I want newer, better documentation, and I want Dave to be free to write what he thinks is best, because as lots of people have already seen; He knows what he's doing.

But I can't see dismissing people as "old-timey" or having "Stockholm-syndrome" will have a positive effect.

It would be great if the "new" and probably "better" OO frameworks had good documentation (there is a lot of man pages for Moose, you can't understand how they relate) and a good community willing to help. Unfortunately that wasn't what I found when I asked for help on #moose.

That said, and with my nerves killing me, I forgot Moose and just implemented my task using blessed references.

So, probably this is not only our fault (we that have Stockholm Syndrome) but also for the guys that implement the probably "better" solution, think they are the best, and do not do much more than that :(

I guess the corollary is that there are people who insist that there is nothing wrong with the alternatives as well.

Well, one of my nieces recently asked me "What's Ghostbusters?" so I guess I can put myself in the leaning-towards-old-guy shelf as well :)

I always rather had the feeling that they aren't against new ways of doing things, but rather fear these techniques that worked for them for so long could be regarded as "wrong."

If you don't really do "full-blown-OO," things like Moose or even accessor generation can be seen as rather unneeded.

The thing is, bless() is still very valid. True, it's really, really low-level. But in the time before Moose, Modern Perl and other recent developments, things like accessors, constructors and destructors were the dominant OO discussions that I remember. Now we talk about type constraints, roles, traits, meta-objects, attributes, delegation, introspection, reflection and all the other goodness the MOP gives us.

I personally couldn't imagine how frustrating it would be to have to implement something like Moose' native array trait delegations manually. But I only have this problem now that it made my life so much easier. But I can very well imagine that some developers problem domains haven't changed in that regard.

There doesn't seem to be a disagreement that Perl developers should know what a blessed reference is, since they're very likely to encounter one sooner or later. The question seems more to be about how we should try to bring in people who don't know Perl that deeply yet.

I personally favor the new approach. But I can't blame people who aren't invested in the "new way" for thinking that people might be led from the core away to CPAN modules. I stopped following the p5p discussion, but it seemed to me what we need is a nice, fast and easy simple accessor/constructor/destructor framework in core. And I don't even think it matters that much which one it is. If I could choose, I'd just vote for something without-too-much-cleverness, readonly by default, and optionally modifiable.

I honestly think as long as the solution helps newcomers get started with OO in Perl quickly, whlie still being useful to a large number of regular users, it doesn't matter if it doesn't do anything. bless() and CPAN are still there, and one can still move forward later on.

Sorry for the long content. As a regular p5p-reader but not-commenter I might have collected a couple of things I wanted to vent about :)

Alberto, you do understand that as someone who wants to use Moose you are part of the community, right? Moose has great docs for some people, but not for others. These others tend to be those that haven't touched Moose or a conceptually related MOP yet.

But the people developing Moose don't have that outside viewpoint that is needed to know what documentation will be really practical in the wild. Dave does an excellent job with the documentations. It's very complete and clear these days. But he's no psychic, he's a Moose user and things that might not be obvious to you could very well be obvious to him. Add to that the factor that many people aren't native English speakers (myself included), and you see why newcomers have to be included in the community. Unfortunately, library projects have a hard time finding volunteers who are interested enough in the project to write documentation, but not interested enough to become an immersed user. That being said, I haven't yet found anyone on #moose to think they're the best. They are proud in their work, and they should be in my opinion.

Such snippy remarks is why people think Perl is unfriendly. Please don't do it in the future.

Yes, change will happen, I agree. That's why I'm personally rooting for a small DWIMy implementation that can simply be ignored once it isn't enough anymore. Looking at CPAN and how long accessor generation has been done there, I don't think the practice itself will subside.

The options that we have as I see them are:

  1. Give up on newer modules in the core
  2. Convince the ones against the inclusion to approve of it
  3. Ignore them and just do it

I feel that the practical solution lies somewhere between the last two points.

Robert, I know they do not have that outside view. But they do not want to have it as well. And yes, I am part of the community, or I was part of the Moose community for some hours. In the other hand, I joined Dancer mostly at the same time, and the community welcomed me, and they have profied (I think) of that. And now, every time a newcomer comes to #dancer with questions, I welcome them as I was welcome.

It's not that they don't want to have the view, they can't have it. You cannot "unknow" the internals. Saying they just don't want to see it is quite harsh. If they wouldn't care, they wouldn't put immense amounts of work into documentation, a consistent API, edge cases and making sure extensions work with newer versions.

The experience you had with Dancer is pretty much the experience I had with Moose, and what I see happening again and again. So it's all just not that black and white.

This is my wishlist for a core OO system (in no particular order):

  • CLOS like
  • supported by dedicated syntax
  • fast compilation & fast runtime
  • its performance penalty should be "proportional" to the set of features actually used.

...or maybe the core should be expanded just enough to allow 3th parties to write this kind of OO systems.

@Salvador - Tcl is taking that route. They are including a minimal though "feature" complete OO system in the core but they are building it in such a way that 3rd party OO extension (snit, XOTcl, ITcl) can benefit from it as well. That would be my suggestion for Perl as well. A small sane way to to OO in the core that lets Moose and others build on top of it. We could use Moose like we are currently using the Perl6 effort, a proving ground for ideas that get backported. I see that as a win-win.

Perl's OO a great idea. It is a great language for those who knows how to use it.

I don't quite get the comments about this being rude or mean spirited. I thought it was clearly intended to be somewhat tongue in cheek, wry humor. Let's all keep our senses of humor intact!

To respond to the topic at hand, I imagine it would be more likely to get bits of a MOP in the core than a full baked solution like Moose. And then maybe with a good built in object protocol, the rest will naturally fall into place over time.

Leave a comment

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book!