5

Many standard modules are all using straight up perl -- problem is these guys arent using Moosey stuff, so I catch myself wrapping them with Moose or reinventing some simple functions in bigger libraries for convenience.

I wondered if there was any general approach to how developers using Moose incorporate other libraries that are non-Moose.

Being new to Perl and Moose I'd like to have a better understanding of how Moose is used in situations like this, or when it is generally preferred to use Moose vs Perl or even MooseX, or some other package, or whether its arbitrary.

Seems like there are different schools of thought, but Perl being as old as it is -- there are too many conflicting sources, so it's hard to navigate to a consistent truth. I'm not sure what to believe!

Anyone have a definitive source they turn to for "modern" usage of perl? Understand I've only been using perl for a month so I'm green to this community.

Updated

I don't want to hurt anybody's feelings by talking about libraries they love in a way they may not appreciate, so I've removed my side commentary about certain libraries Ive used to refocus on the question at hand.

Thanks for your guidance!

qodeninja
  • 10,946
  • 30
  • 98
  • 152
  • 1
    "I mean why do you need a whole cgi library to parse headers anyway?" If it was as simple as you say, we wouldn't need libraries for it, would we now? – Chris Lutz Oct 14 '11 at 22:45
  • 8
    @nodebunny The appearance of simplicity is deceptive. CGI.pm has been around since the 90's. It's undergone more than 100 version updates since then, and probably half of them have at least one line of code fixing something dealing with parsing queries. It represents hundreds of man-hours of work and many thousands of hours of real-world testing. But feel free to reinvent it when you have nothing better to do. – DavidO Oct 14 '11 at 23:55
  • 5
    Why do you need to Moosify these modules? What convenience are you looking for? – ErikR Oct 15 '11 at 00:06
  • +1:DavidO - many of the things I wanted to say, which I'm putting in my answer – vol7ron Oct 15 '11 at 00:27
  • 4
    It is not about our feelings being hurt. Over the this week alone, I saw several questions posted here with some copying from some web page which had copied from someone else some other idiot's hand rolled CGI parsing 'technique'. These things are tricky to get right, and are the gaping security holes. – Sinan Ünür Oct 15 '11 at 01:15

2 Answers2

13

While I do not know what others do, I would be very reluctant to create myself extra work. I do not see any general need to Moosify a bunch of modules that already work.

If you want to inherit from non-Moose modules, take a look at MooseX::NonMoose.

If the HTML generation cruft in CGI.pm bothers you, you can use CGI::Simple.

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
0


About Reinventing CGI

CGI is a library which has been thoroughly tried and tested and if it needs improvement, you could build an extension, or contribute/contact the maintainers. You have to remember that modules are only as good as their track record (reliability) and their upkeep. Many people created decent modules, but didn't continue maintaining it, so they sort of fell to obscurity.

CGI is a boat all of its own, which if you think there's a lot of overhead, you could use CGI::Simple or CGI::Minimal. CGI.pm does more than parse querystrings, it also has cookie management (sessions), HTML generation, and other useful functions.

Others have had some criticisms of the overhead with CGI.pm, but that's why they developed FastCGI, which is modifying the server to use a persistent state of the script, thus loading the overhead once, rather than on every page load.

It is possible for you to create another (even better) version, but why bother? Many people may probably tell you, you shouldn't reinvent the wheel, with good reason. CGI has been around for almost 2 decades, with so many users testing it, finding holes, and having patched the holes; however, I'm never a big fan of saying "you shouldn't do something." If you think something could be better, make it better. There are many OSes that exist today just because of that reason, why settle for something that does 95% of what you need, if you need that other 5% too? But I also say, weigh your costs vs. benefits and determine if you want to devote your time to this, or if maybe there's another problem out there that has yet to be solved, that could use a little more manpower. To have something successful, you're going to need to test it thoroughly, and will most likely need to create something that other people would want and (at this point) there isn't much of a reason for CGI-users to be motivated to switch.


About Modern Perl

I think "modern Perl" is an oxymoron. I would jokingly call modern Perl; Ruby or Python.

That isn't to say that Perl isn't useful, because it is, but it's been around a long time. While it has had its significant share of changes from version to version, the most popular, Perl5, hasn't changed all that much; mind you, my definition of change is not adding to the language (new operators and functionality), but deprecating/replacing old features or changing the behavior of existing ones (like for/foreach loops).

Note: Perl6 could be considered modern perl (and does have many significant changes), but it's not widely adopted and was supposed to be released many many years ago (it's the Duke Nukem 4 Ever of programming languages).


About XS

I haven't done much module programming, but if memory serves correct, XS is the interface between Perl and C, which I think allows you to compile your perl modules for faster execution. Consider the PostgreSQL DBI module. There's a DBD::PgPP, which is a pure perl module to interface with Postgres, but there's also DBD::Pg, which I think compiles some of the code using C and takes advantage of some other OS utilities. Compiled modules have the benefit of faster load and execution (there may be some better resource management in there too).

vol7ron
  • 40,809
  • 21
  • 119
  • 172
  • thanks for the background info on this +1, this isnt about CGI at all though lol-- I dunno why everyone is jumping on that. This is about Moose! =P It seems my side comments became the focus instead of the question. I'd give you another +1 if I could for the XS info though, thanks again. – qodeninja Oct 15 '11 at 00:48
  • @nodebunny: here's some of the official info: http://perldoc.perl.org/perlxs.html , I probably should have read it before posting – vol7ron Oct 15 '11 at 01:29