Re: [MacPerl] RE:[Macperl]Introduction

[David Steffen <steffen@biomedcomp.com>]

Hi Annalisa,

A lot of your questions have been answered, but I will put in my $0.02.

>Modules...modules are the most elusive things to me. I understand that
>modules are like libraries of packages. I just don't understand how they
>get installed with "makefile.pl"

I am not an expert (IANAE), which means I may make mistakes on the one
hand, but may give a more down to earth explanation on the other.

Most modules you will want to use come installed in the distribution so you
don't have to install anything.  (This is true, for example, for CGI.pm.)
For a pure Perl module, just having it anywhere contained in @INC means
that it is available, thus it is easy to "hand install" someone else's
module in such cases or your own Modules.  Writing your own module is
relatively easy, by the way, and is a practice I find very helpful in
organizing code.

Once you have a module on any path specified in @INC, all you have to do to
access CGI.pm (for example) is to include the line...

use CGI;

...near the beginning of your program.


>I also don't understand how you are the site/perl folder relates to the
>@INC so that the script knows to look there.

@INC is just an array of paths where perl looks for files like perl modules.
1) Usually it is fine the way it is, especially in MacPerl.  For "out of
the box" MacPerl, there are three places you can put things like modules:
in the folder named lib in the MacPerl folder, in the folder named
site_perl in the MacPerl folder, or in the folder your Perl script is in.
There is nothing magic about this, this is just how MacPerl is initially
set up, but I have never had need to change it.
2) It is astonishingly easy to set the default in MacPerl: Edit Menu;
Preferences...; and then click on the libraries button.  (IANAE, but it is
my impression that it is harder to reset the default under Unix.)
3) I believe that it can be reset within your program, but this is not
something I have ever had occasion to do.

>My biggest problem is with directories and permissions. But I am
>assuming that there are no permissions required if using MacPerl rather
>than straight Perl on Unix.

...and permissions are typically only a problem for cgi's.
1) This is not really a big problem.
2) To a large extent what you can and should do is determined by the
administrator of the system on which you a working.
3) This is off topic (not that we are all that fussy about that here).

Given how you have defined your goals, I bet you will have to deal with
this at some point, but I think your plan of learning Perl with MacPerl and
then learning the additional complications that come with a Unix system
later is a good one.

>>3) Perl is not my favorite OO language.
>I guess my premise is that if I learn the OO aspects(which I've wanted
>to understand even before wanting to learn Perl) then going "procedural"
>will be easy.

I don't believe this is true.  In the first place, as someone has already
pointed out, you really need to be comfortable with the conventional
aspects of Perl before you can realistically write Perl objects.  In the
second place, if your primary interest is OO programming, Perl is the wrong
language to start with, in my opinion.  (I would suggest Python or Java,
depending on your goals, your dedication, your resources, etc.)

>I just want to use perl for doing CGI stuff and I know that there are tons
>of modules out there to use. And if I want to do that I will need to
>understand the OO parts of Perl, or do I?

1) Most modules, in my experience, are "object free".
2) As someone else pointed out, you can use CGI.pm via object interfaces or
via conventional interfaces.
3) As I said before, USING objects in Perl is easy.  CREATING objects in
Perl is harder.  Learning how to use the OO features of CGI.pm or any other
module is no big deal, in my opinion.

>I would be very interested WHEN you find CGI.pm inappropriate, and when
>it covers the wierd gotchas.

I'm sorry, I must not have been clear.  I pretty much use CGI.pm for all
production code so that I can worry less about wierd gotchas.  The only
time I might not use CGI.pm is for a quick experiment.  What I meant to say
is that it is probably EASIER to write a simple cgi WITHOUT CGI.pm, but it
is SAFER to use CGI.pm.  Also, as someone else pointed out, it might be
more educational to begin by NOT using CGI.pm.

-David-

David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com



===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org