OO Perl
Matt
I've been using perl for the last 5 or 6 years and in the past 2
years I've been doing things in a much more object oriented style.
I'm just wondering how many people out there in the Perl community are
using Perl as an OO solution rather than a different OO language, like
Ruby. I know Ruby's popularity has really taken off in the past few
years with the growth of Rails. I'm curious to see if people are
opting to use a language like Ruby with Rails over using Perl....since
Perl's OOness is a bit...forced.
Just wondering. Also, over the years I've developed sort of my own
Perl OO style, if anyone is interested in using some of the Perl OO
helper methods I've developed (or reviewing/critiquing )....let me
know.
Thanks!
Matt
Lars Eighner
<c5c123fe-7f92-4c9d...@d1g2000hsg.googlegroups.com>,
the lovely and talented Matt
broadcast on comp.lang.perl.misc:
> Hello everyone,
> I've been using perl for the last 5 or 6 years and in the past 2
> years I've been doing things in a much more object oriented style.
You're the one! Please! Stop encouraging them.
--
Lars Eighner <http://larseighner.com/> use...@larseighner.com
Save the whales! Collect the whole set!
bugbear
> Hello everyone,
> I've been using perl for the last 5 or 6 years and in the past 2
> years I've been doing things in a much more object oriented style.
> I'm just wondering how many people out there in the Perl community are
> using Perl as an OO solution rather than a different OO language, like
> Ruby.
I use OO techniques in perl for the same reason
I use them in other languages - they're effective.
BugBear
Peter Scott
> I'm curious to see if people are
> opting to use a language like Ruby with Rails over using Perl....since
> Perl's OOness is a bit...forced.
You...noticed.
> Just wondering. Also, over the years I've developed sort of my own
> Perl OO style, if anyone is interested in using some of the Perl OO
> helper methods I've developed (or reviewing/critiquing )....let me
> know.
Sure, provided you first check on what has already been done in this area,
because OO helper modules/style/methods have been done practically to
death and your chances of reinventing a wheel are high, If you don't know
what Moose is, start there.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
Matt
language" is done in Modules - which is the way its done, but that
just doesn't work for me. I don't want to install Moose and any of
the other Module dependencies it may have. The tooling to make
installing Modules for Perl just doesn't exist..here is an example.
I've got a web server - which I rent for a monthly fee. I'm not an
admin on that server, and I don't have root access. So any Perl
modules that I install must be to MY directory only...which I know can
be done, but the thing is that when I develop in my local environment
I can't just deploy my code to my web server, I have to make sure that
the Perl modules installed on my local machine are also installed on
my remote server. I've gotten sick of doing that, so I've decided
that I'm going to break the mold. I don't want to develop Perl
modules the way its always been done, I want to do it in a way that
works for me. I've got my OO Perl stuff in a directory, if I change
it, I deploy it from my local server to my remote server, no other
changes needed. On my remote server, I know its there because I
deployed it there. I didn't have to bring up an SSH session and log
into the remote server for anything. What I've done with my OO Perl
"module" is that I've made it completely independent from any and all
other Perl modules. This way I've got all the code I need without
having to worry about installing any additional Modules locally or
remotely.
Hope that makes sense...I'm sure it probably won't to most of you.
Thanks,
Matt
Peter J. Holzer
Your approach is slightly simpler if you have only one module, one
project and one server.
That advantage vanishes if you have several projects on several
servers using several of your modules. Now you need to keep track of
which modules you need to deploy on which server, exactly as if you used
modules from CPAN. And unlike CPAN, your system for deployment probably
doesn't keep track of dependencies.
hp
Matt
> servers using several of your modules. Now you need to keep track of
> which modules you need to deploy on which server, exactly as if you used
> modules from CPAN. And unlike CPAN, your system for deployment probably
> doesn't keep track of dependencies.
I don't quite follow. If you have multiple projects on multiple
servers and a module that you're using changes, regardless of if
you're using a CPAN module or not you'll still have to update ever
server for every project. The thing about my OO Module is that there
are NO dependencies...the only thing you need is a clean Perl (5.8.8)
installation. In my mind I'm trying to compare this to a Java
Enterprise Archive. You've got an EAR file that contains a bunch of
Java Archive files...if you need a new version of a JAR file, you
download it, and replace that in your ear...it only impacts that one
application and you don't have to worry about regression testing every
single application on that server...when you install a Perl module you
could potentially impact anything on that server unless you install it
to a specific directory (right?). What happens if you've got 200
projects on a server that are all unrelated. If you have a module
that you want to install but you don't want to have to regression test
all other 199 projects you install it to a specific directory, or
something, right? What if 50 projects need that module? Do you have
to install that module 50 times to those specific directories? Do you
have to reorganize the entire directory structure so that you can
install a Perl module for a group of projects? How do you manage a
group of 50 that need 1 module and a group of 100 that need a
different module...what happens if there is overlap? Sorry for the
novel. If somebody can clarify how this would work using CPAN Modules
installed the "standard" way, I'd really appreciate it.
Thanks!