OO Perl Usage

[tqisjim]

I recently published a CPAN module called XML::Parser::Nodes. Basically, I'm moving code out of my personal libraries. I almost always/only code in OO Perl, and I've modified many common packages to provide a more reusable OO framework. For example, I usually subclass XML::Parser::Nodes any time I'm using XML.

The pedigree of XML::Parser goes back to Larry Wall himself, and I'm shocked at my chutzpah to imagine that I can publish an improvement. Well, maybe not shocked, but a little puzzled.

My puzzlement has given way to speculation: I realize my commitment to Perl is putting me within a tinier and tinier community of developers. But it just occured to me that it's worse than I thought, if I'm one of the *very* few that develops OO Perl applications.

Someone recently told me he didn't know Perl had OO capabilities, and I see very few discussions on the topic. If Perl OO actually never caught on (and I was too busy to notice), that would explain quite a few questions, like, why is it so easy for *others* to migrate to PHP?

This isn't so much a technical question. Posted here because presumably most of the monks have enough experience and longevity to offer a perspective about how Perl is used now and historically. Admittedly, my posts don't seem to attract much attention on PerlMonks. Maybe someone can recommend an alternative forum.

Anyway, does anyone have a firmer sense that they can share? Thanks!!!

[Your Mother]

You might check out XML::Rabbit. It's a perfect marriage of XML and OOP. XML::Parser is a bit of a dinosaur. There are many better/easier modules from a speed or UX perspective; the posts about them here are quite frequent. And what roboticus++ said.

OO is thriving in Perl.

[roboticus]

tqisjim:

There are far too many object (Moose, Mouse, Moo, Class, etc.) systems in Perl and too many things that build on objects (Dancer, Catalyst, DBIc...) to imagine that there only a few developers who use OO. I think a more plausible argument might be XML is annoying enough that many developers ignore it, and of the perl developers that do, they've found an XML package that works close enough to their liking.

Disclaimer: I do only a little OO programming in perl. Most of my stuff is just quick hacks.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[ForgotPasswordAgain]

Your disclaimer of tending to quick hacks points to another possibility: of Perl devs dealing with XML, many probably don't bother with an XML package.

[roboticus]

ForgotPasswordAgain:

Good point ... especially as evidenced by some questions on parsing XML with regexes...

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[GrandFather]

Perl is a massive toolbox that you can use to solve a vast array of problems. But for any particular problem only a modest selection of the tools are likely to be used. Most people end up using only the tools on the top two trays of the toolbox and from time to time use the wrong tool for the job - you can drive screws with a hammer, but the result tends to be nasty, and you can drive nails with a screwdriver, but it's slow and hard work (and you're more likely to hit your thumb).

OO tends to either be down on the third shelf and probably not even noticed, or up on the top shelf and used all the time (I'm a top shelf person). There is plenty of other stuff buried down among the bent nails and mashed headed screws in the bottom of the toolbox that almost no-one finds, and occasionally they are exactly the right tool to solve a tricky problem.

At the end of the day all that really means is that Perl is a very rich language and TIMTOWTDI.

[bitingduck]

Looks useful and easy to use-- I'll probably check it out in the next week or so. Like roboticus, most of what I do is quick hacks of a page or so rather than applications, but unlike him, a large fraction of it is XML in one form or another. I've been playing in the ebook world, and just about everything seems to be some kind of XML. I end up using a bunch of different modules depending on how complicated the thing I'm dealing with is.

And I actually prefer XML over YAML and JSON. I think it's generally easier to make sense of if you're looking at it in isolation

edit: And to address the OO topic-- I tend to use OO based modules. It's not something that I really think about too much, as I look more for whether they do what I want easily than OO or not.

[Faern]

You might consider a hybrid blend of CGI::Application and Template::Toolkit to create an MVC. https://docs.google.com/document/edit?id=1N4kKoy-79ih1E78859mzHgEU1aZv1uakGqhH5OTQxok&pli=1#