OO Perl

[Matt]

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 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]

In our last episode,
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.

 

[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.

 

[Matt]

Here is the thing. Everything that's done is Perl to "extend the
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]

Here is the thing. Everything that's done is Perl to "extend the
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.

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]

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.

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!

 

[Peter J. Holzer]

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.

Yep. So you don't win anything by "rolling your own".

The thing about my OO Module is that there are NO dependencies...

As I said, it seems simpler because you have only one module. But you'll
write other modules which will use your OO module. And then you do have
a dependency: Your other modules depend on your OO module and you have
to install your OO module too if you want to use your other modules.

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?).

You could install all modules for a specific application into a specific
directory. Then installing that module only impacts that application.

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?

If you want to do that, yes. Personally, I don't. I prefer to keep a
single version of each module on the server (and on other servers, too,
if possible).

What if 50 projects need that module? Do you have to install that
module 50 times to those specific directories?

Yes. Same as with the Java. If you want thar Jar-File in 50
applications, you have to include it in 50 EARs, which means that it
will be installed 50 times on the server. (Actually, with the
pointy-clicky Java-IDEs it will probably be included 3 or 4 times in
each EAR, so it will be installed 150 to 200 times ;-)).

Do you have to reorganize the entire directory structure so that you
can install a Perl module for a group of projects?

You can certainly do that. @INC gives you all the freedom you need.

How do you manage a group of 50 that need 1 module and a group of 100
that need a different module...

I don't understand that question. Isn't your previous sentence the
answer?

what happens if there is overlap?

Either you define a super group, or you install it for each group which
needs it.

Sorry for the novel. If somebody can clarify how this would work
using CPAN Modules installed the "standard" way, I'd really appreciate
it.

In a previous posting you wrote that you already know how to do it with
CPAN modules, but that you found that too cumbersome. If you have a
specific question someone here can probably answer it.

hp