On Wed, 2003-01-22 at 14:44, Rob Richardson wrote:
> Greetings!
>
> With Version 2.0 of the train crew volunteer signup form program about
> to go online, I am now turning my attention to Version 3.0, which will
> be Done The Right Way.
>
> To start with, I am going to create a class named Train. A train has a
> name, a date, a crew call time, and a bunch of people working on it.
> So I am creating a file named Train.pm. Since it's not a good idea for
> users of a class to know about what's inside the class, I'll have a
> bunch of accessor methods. Here's what I have so far:
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> package Train;
> require Exporter;
> @ISA = qw(Exporter);
> @EXPORT = qw(Load
> SetName
> GetName
> SetDate
> GetDate
> SetCrewCall
> GetCrewCall
> AddCrewMember
> GetCrewList
> new);
>
> sub new
> {
> my $self = {}; # $self is a reference to an anonymous, empty (for
> now) hash
> bless $self;
> return $self;
> }
>
> sub SetName
> {
> my $self = shift; # This is the "%self" that is flagged as an error
> $self{name} = shift;
> }
>
> I have a couple of questions.
>
> When I run perl -c to check this, it complains that @ISA, @EXPORT and
> %self are global symbols that need explicit package names. Why is
> this? I haven't seen @ISA or @EXPORT qualified with package names in
> any samples. What package name do I need to use? (I solved %self. It
> should have been $$self{name}.)
A "neater" less ambigious way of doing that is probably:
$self->{'name'} = shift;
>
> I tried reading the perldoc pages about object-oriented programming,
> perlobj and perltoot. I was surprised (to say the least) to come
> across the following quote in perltoot:
> "By proper design, we mean always using the two-argument form of
> bless(),
That is always a good idea... the two argument form of bless that is...
try this for your new method instead:
sub new {
my $proto = shift;
my $class = ref($proto) || $proto;
my $self = {};
bless $self, $class;
return $self;
}
> avoiding direct access of global data, and not exporting
> anything."
> But I thought exporting was how a script that uses a module knew what
> the module had to offer! If I say "use Train", doesn't my Train.pm
> module have to export the methods that let the train objects actually
> be used? If I don't need to export methods here, when do I need to
> export them?
You don't need to export them... What you are doing by putting the
methods/functions in the Export array is literally "exporting" them to
the callers namespace - this is a bad idea because you might have a
conflict with anther module that uses the same method names.
eg (as you have it)
use Train;
will make the methods SetName, ... available just as bare
subroutines... aka, i can say:
&SetName(...)
in my module.
That is bad because, what if you are also saying "use Car" which also
exports the SetName method?
A better idea is to use EXPORT_OK - so that if a user wants to import
the method into their name space, they explicitly have
to do so. eg:
use Train qw(SetName);
I never export anything and always get the user to use the methods
as:
class method:
Train->SetName(...);
object method (which is what i think you really want):
my $train = new Train;
$train->SetName(...);
simran.
>
> Confusedly,
>
> RobR
>
>
>
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
