[28867] in Perl-Users-Digest
Perl-Users Digest, Issue: 111 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 9 22:41:15 2007
Date: Fri, 9 Feb 2007 19:40:37 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 9 Feb 2007 Volume: 11 Number: 111
Today's topics:
Multiple Classes per File and use (was: OO Perl...) <please@nospam.net>
Re: Multiple Classes per File and use (was: OO Perl...) xhoster@gmail.com
Re: Multiple Classes per File and use (was: OO Perl...) <please@nospam.net>
Re: Multiple Classes per File and use (was: OO Perl...) <1usa@llenroc.ude.invalid>
Re: Multiple Classes per File and use <uri@stemsystems.com>
Re: Multiple Classes per File and use <bik.mido@tiscalinet.it>
Re: Multiple Classes per File and use <uri@stemsystems.com>
Re: Multiple Classes per File and use <bik.mido@tiscalinet.it>
Re: Multiple Classes per File and use <uri@stemsystems.com>
Re: Multiple Classes per File and use <bik.mido@tiscalinet.it>
Re: Multiple Classes per File... <please@nospam.net>
Re: Multiple Classes per File... <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 05 Feb 2007 14:49:14 -0800
From: Xiong Changnian <please@nospam.net>
Subject: Multiple Classes per File and use (was: OO Perl...)
Message-Id: <please-B884D9.14491405022007@free.teranews.com>
Okay, thanks for help given -- the most helpful thing was the naked
assertion that multiple classes *may* be coded into a single file. I now
have my test case working.
My problem seems not to have anything to do with Mac filesystem but it
may. The issue is that I lost heart when I could not seem to get methods
recognized even though I had these nice use and base declarations in
each file.
For the following, I've translated folders into *nix directory
conventions.
The .pl testbed itself is in /usr/; there is a subdir /usr/Jam/ which
contains, in Band.pm, the putative "important" class and, in Guts.pm,
three "helper" or "internal" classes.
It seems that I must use Jam::Band; I can't use Band. On the other hand,
I must use base qw(Band) and not use base qw(Jam::Band). You'll forgive
me if I find this inconsistent. I'm sure there's a good reason; I just
don't see it.
I've always put the package declaration first, ahead of use statements;
it seems logical that if I'm declaring multiple packages, I may as well
put the use statements before the first package. I feel it might be best
to keep the package first, though, in single-class files.
I'm still not sure if I *must* use base for each class, so long as they
all inherit from the same branch. This should, I suspect, always be the
case; let there be another file for classes that inherit from another
branch but group the tiny helper classes that are all "siblings" in one
file. This is something I can thrash out by experiment.
Again, thanks for the prods. I beat on this for hours with no success
but it all started to work when I began to believe it could be done.
Xiong
### /usr/jamsession.pl ###
use strict;
use warnings;
use Jam::Band;
...
my $one = new Band;
$one->add('Tuba','whonk');
$one->play('Tuba');
...
### /usr/Jam/Band.pm ###
package Band;
use strict;
use warnings;
use Jam::Guts;
sub new {
...
};
sub add {
...
my $instrument = new $kind;
$instrument->tune($sound);
$obj->{$kind} = $instrument;
};
...
...
### /usr/Jam/Guts.pm ###
use strict;
use warnings;
use Jam::Band;
package Tuba;
use base qw(Band);
sub tune {
...
};
package Drum;
use base qw(Band);
sub tune {
...
};
...
...
######
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: 06 Feb 2007 04:24:34 GMT
From: xhoster@gmail.com
Subject: Re: Multiple Classes per File and use (was: OO Perl...)
Message-Id: <20070205232520.458$7y@newsreader.com>
Xiong Changnian <please@nospam.net> wrote:
>
> The .pl testbed itself is in /usr/; there is a subdir /usr/Jam/ which
> contains, in Band.pm, the putative "important" class and, in Guts.pm,
> three "helper" or "internal" classes.
>
> It seems that I must use Jam::Band; I can't use Band.
You could use Band as long as /usr/Jam was in the perl lib path, or if you
run the script with a cwd of /usr/Jam. If neither of these is the case,
then you need the Jam:: or else perl doesn't know to look for Band in the
Jam directory. Presumably you only want /usr in your perl lib path, and
you want this to refered to as Jam::Band, right?
> On the other hand,
> I must use base qw(Band) and not use base qw(Jam::Band). You'll forgive
> me if I find this inconsistent. I'm sure there's a good reason; I just
> don't see it.
See the next item below.
...
>
> ### /usr/Jam/Band.pm ###
>
> package Band;
If you want to refer to this as Jam::Band in other classes "use base"
lines, then the "package" statement would need to declare it as such:
package Jam::Band;
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Tue, 06 Feb 2007 10:41:59 -0800
From: Xiong Changnian <please@nospam.net>
Subject: Re: Multiple Classes per File and use (was: OO Perl...)
Message-Id: <please-10E2DD.10415806022007@free.teranews.com>
Uh, thanks to Xho for explaining why I use Jam::Band but use base Band
when I package Band. Sorry if I'm stubborn and cranky but well, I still
find it inconsistent.
But if I can use Jam::Band and use base Jam::Band if I package
Jam::Band, then I will sleep better. Thanks.
In article <x7k5yw9reh.fsf@mail.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
> i think 20 related classes means you are over classifying things. that
> is the java and not the perl way. do they really need to be separate
> classes? are they all variants of each other or a parent class? are you
> reusing them in different places or only all at once? whenever i see too
> many of anything in one place i suspect a design flaw.
Ah, I covered my application in too much detail in an earlier thread;
I'd better not repeat myself. Yes; yes they are all related but although
they can reasonably inherit a few methods, some will be distinctly
different; they will be used in a wide variety of configurations; and I
agree.
The nub of it is that some objects (classes, but bear with me) logically
include others, just as Dinner includes Entree and Desert. This makes
sense to the user of the -- Restaurant *thing* (Not a module, not a
bundle, the whole folder full of related stuff = project?). Meanwhile,
it seems that most of these objects have similar structures. For
instance, every one of my logical objects has a first-level SELF key,
pointing to a small hash with keys like NAME and COLOR. Other
first-level keys may point to sets of objects or arrays of data.
The point being that since each of these objects has a SELF key/hash
containing similar data, it makes sense to me to build a Self object and
write general methods to handle it. Self has no "external" meaning to
the outermost, using script; perhaps I should call it _Self. There are
already a couple cases like this and by the time the entire *thing* is
written, I expect about 10 logical objects and perhaps another 10
internal helper objects. What I'm doing, without going into too much
detail, really does involve a lot of distinct classes of things --
things that behave in fundamentally different ways, not just dozens of
instances of the same class.
I agree that my current method, in which I tried to limit myself to
logically sensible objects and went bashing around with symbolic refs,
is ugly and Bad. That's why I posted here: I was happy I got it to work
and immediately looked for a better solution.
Now, I've got that silly example working and I'm (momentarily) content.
One top class in its own file with new() and other general cross-project
methods; one file each for the big, external classes; one helper file
for all the small _internal classes; and all inherit from the top.
I really can't thank you guys enough.
> use named variable when possible.
> it makes for more easily understood code.
Sorry, I haven't the faintest idea what you're driving at, unless you're
already talking about the symref -- and that comes in the next line.
Maybe you just want me to deref to a temp variable before proceeding.
I'm content to jam it all in one line.
I'm from the days when absolutely everything had to be declared and
reserved; every single operation was one instruction at a time.
Sometimes one machine-language instruction actually ran to more than one
line of code.
I'd spend a week writing the equate table before typing the first line
of executable -- and that would be at address 0, and I knew it was at 0,
and I knew it had to be the system boot because when the power came on,
the processor would start at 0, god willin ana river doan rise. If I
wanted to loop, I had to declare and maintain the whole structure and
no, I didn't trust the assembler to put things where I wanted. I'd
assemble and dump it onto 132-col greenbar and check the hex. Up to me
which register to use for the count and all my fault if I picked wrong.
Sometimes I patched shipping firmware directly in hex -- code, not
constants. I don't do that anymore.
When I iterate over an array without knowing, anywhere, the loop
iterator even exists I get a little woody. :P You see the verbose
version of my code. Yes, I know, it's a sin. Sorry.
> XC> &{"report_" . lc($_)} ($ref->{SETS}{$_})
>...make a dispatch table...
Oooh, sorry, but I sort of disagree. Maybe better than blatantly
constructing the sub name out of sticks and pebbles on the fly but a
jump table is a jump table, no matter what you call it. I'm looking for
more elegance.
Please relax; I have no intention of really using what I call a
"calculated jump". As I posted, that's the first thing to break. Last
time I tried that for a client on a serious project, was 20 years ago
and I thought I was cool. I only did it because it could be done -- and
because nobody had ever educated me as to why it might be risky.
Also, please breathe easy about the multiple objects. I'm off the clock
on this; it's a personal project. I can afford to go in the wrong
direction for a long time, learn something while I'm there, and
mercilessly refactor until the chrome gleams.
Still, thank you for your concerns.
Xiong
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Tue, 06 Feb 2007 20:04:48 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Multiple Classes per File and use (was: OO Perl...)
Message-Id: <Xns98CF996514C0Casu1cornelledu@127.0.0.1>
Xiong Changnian <please@nospam.net> wrote in
news:please-10E2DD.10415806022007@free.teranews.com:
> Uh, thanks to Xho for explaining why I use Jam::Band but use base Band
> when I package Band. Sorry if I'm stubborn and cranky but well, I
> still find it inconsistent.
You are sounding cranky and stubborn and I don't see why you should be.
This is very straightforward. I think a ninth read of the relevant docs
is in order.
> But if I can use Jam::Band and use base Jam::Band if I package
> Jam::Band, then I will sleep better. Thanks.
Put Band.pm in
/usr/Jam
In Band.pm, declare the package:
package Jam::Band;
If you want to use Jam::Band in a script
use lib '/usr';
use Jam::Band;
If you want to inherit from it:
use lib '/usr';
use base 'Jam::Band';
It is all very consistent. In a use statement, :: map to the directory
separator and the last word (in this case Band) maps to the .pm file.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and
reverse each component for email address)
comp.lang.perl.misc
guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 07 Feb 2007 15:51:57 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Multiple Classes per File and use
Message-Id: <x7hctx7ksy.fsf@mail.sysarch.com>
>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:
XC> But if I can use Jam::Band and use base Jam::Band if I package
XC> Jam::Band, then I will sleep better. Thanks.
XC> In article <x7k5yw9reh.fsf@mail.sysarch.com>,
XC> Uri Guttman <uri@stemsystems.com> wrote:
>> use named variable when possible.
>> it makes for more easily understood code.
XC> Sorry, I haven't the faintest idea what you're driving at, unless you're
XC> already talking about the symref -- and that comes in the next line.
XC> Maybe you just want me to deref to a temp variable before proceeding.
XC> I'm content to jam it all in one line.
you used a for loop with the implied use of $_ as the loop variable. it
is better to use a named lexical variable instead like this:
for my $foo ( @bars ) {
it makes the code easier to understand since the loop body will have
that name to help document it. i only use $_ in map/grep where it is
required and in special cases where it works better.
XC> I'm from the days when absolutely everything had to be declared and
XC> reserved; every single operation was one instruction at a time.
XC> Sometimes one machine-language instruction actually ran to more than one
XC> line of code.
you don't have to tell us your background regarding declarations. most
of the regulars here know multiple langs and know all about this area.
XC> When I iterate over an array without knowing, anywhere, the loop
XC> iterator even exists I get a little woody. :P You see the verbose
XC> version of my code. Yes, I know, it's a sin. Sorry.
but you didn't use an explicit loop iterator variable but the default
$_.
XC> &{"report_" . lc($_)} ($ref->{SETS}{$_})
>> ...make a dispatch table...
XC> Oooh, sorry, but I sort of disagree. Maybe better than blatantly
XC> constructing the sub name out of sticks and pebbles on the fly but a
XC> jump table is a jump table, no matter what you call it. I'm looking for
XC> more elegance.
XC> "calculated jump". As I posted, that's the first thing to break. Last
XC> time I tried that for a client on a serious project, was 20 years ago
XC> and I thought I was cool. I only did it because it could be done -- and
XC> because nobody had ever educated me as to why it might be risky.
this is very wrong in several ways. it is a symref which you said you
don't want to do and no one recommends that you do. it is not testing if
the sub exists or not. it is a potential source of future bugs (all
synrefs are). it uses the symbol table as a general purpose hash when it
should be only used to mung the symbols. you can make the dispatch table
a lexical hash whics is safer (more private) and you can pass it around
or store it in something else like an object (can't be done with symrefs
since they are global). so there are many reasons to use a dispatch
table and none that support using symrefs there. you asked for advice on
coding and this is one answer you shouldn't ignore regardless of your
taste and style. it is BAD coding to use symrefs if there is a better
way to do it. that is why use strict disallows them.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 08 Feb 2007 17:22:45 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Multiple Classes per File and use
Message-Id: <grims2d7ik7nb9k13ut97lno7gftmeheeo@4ax.com>
On Wed, 07 Feb 2007 15:51:57 -0500, Uri Guttman <uri@stemsystems.com>
wrote:
>you used a for loop with the implied use of $_ as the loop variable. it
>is better to use a named lexical variable instead like this:
>
> for my $foo ( @bars ) {
>
>it makes the code easier to understand since the loop body will have
>that name to help document it. i only use $_ in map/grep where it is
>required and in special cases where it works better.
Oh c'mon! This is just *so* controversial... even slightly
flame-baiting... I use $_ all the time in loops, provided they're
short enough. If possible I cast them in a statement modifier form,
even. If code is self explanatory it is... err, well, self
explanatory. Of course I would never recommend to use $_ with a for
loop having a main block of 25 lines!!
> XC> "calculated jump". As I posted, that's the first thing to break. Last
> XC> time I tried that for a client on a serious project, was 20 years ago
> XC> and I thought I was cool. I only did it because it could be done -- and
> XC> because nobody had ever educated me as to why it might be risky.
>
>this is very wrong in several ways. it is a symref which you said you
>don't want to do and no one recommends that you do. it is not testing if
[snip]
I wholeheartedly agree with you, but some details, including the
"calculated jump" one above make me suspect that the OP really
misunderstood the meaning of "dispatch table", in which case I renew
the invite for him to look it up.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 08 Feb 2007 12:56:45 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Multiple Classes per File and use
Message-Id: <x7hctw4joi.fsf@mail.sysarch.com>
>>>>> "MD" == Michele Dondi <bik.mido@tiscalinet.it> writes:
MD> On Wed, 07 Feb 2007 15:51:57 -0500, Uri Guttman <uri@stemsystems.com>
MD> wrote:
>> you used a for loop with the implied use of $_ as the loop variable. it
>> is better to use a named lexical variable instead like this:
>>
>> for my $foo ( @bars ) {
>>
>> it makes the code easier to understand since the loop body will have
>> that name to help document it. i only use $_ in map/grep where it is
>> required and in special cases where it works better.
MD> Oh c'mon! This is just *so* controversial... even slightly
MD> flame-baiting... I use $_ all the time in loops, provided they're
MD> short enough. If possible I cast them in a statement modifier form,
MD> even. If code is self explanatory it is... err, well, self
MD> explanatory. Of course I would never recommend to use $_ with a for
MD> loop having a main block of 25 lines!!
i wouldn't call it controversial or flame baiting. you can disagree with
it but most style guides (PBP included) recommend named variables
whenever possible. sure it is a style issue but i am a strong advocate
of named variables as part of an overall style. and i emphasize choosing
quality names which makes it work even better.
XC> "calculated jump". As I posted, that's the first thing to break. Last
XC> time I tried that for a client on a serious project, was 20 years ago
XC> and I thought I was cool. I only did it because it could be done -- and
XC> because nobody had ever educated me as to why it might be risky.
>>
>> this is very wrong in several ways. it is a symref which you said you
>> don't want to do and no one recommends that you do. it is not testing if
MD> [snip]
MD> I wholeheartedly agree with you, but some details, including the
MD> "calculated jump" one above make me suspect that the OP really
MD> misunderstood the meaning of "dispatch table", in which case I renew
MD> the invite for him to look it up.
well, i took calculated jump as the symref since that is a calculated
name of the sub to call. but later the OP seemed to agree with me so i
am confused as to whether he is going to use a dispatch table.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 08 Feb 2007 23:31:06 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Multiple Classes per File and use
Message-Id: <p19ns25tdrajupoeh2s34qq2p90no2gflh@4ax.com>
On Thu, 08 Feb 2007 12:56:45 -0500, Uri Guttman <uri@stemsystems.com>
wrote:
>i wouldn't call it controversial or flame baiting. you can disagree with
>it but most style guides (PBP included) recommend named variables
>whenever possible. sure it is a style issue but i am a strong advocate
>of named variables as part of an overall style. and i emphasize choosing
>quality names which makes it work even better.
Well, PBP (and Perl::Critic) is somewhat controversial too. Some
knowledgeable and respectful Perl hackers beg to differ on some
specific points.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 08 Feb 2007 21:32:34 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Multiple Classes per File and use
Message-Id: <x7fy9g2h8d.fsf@mail.sysarch.com>
>>>>> "MD" == Michele Dondi <bik.mido@tiscalinet.it> writes:
MD> On Thu, 08 Feb 2007 12:56:45 -0500, Uri Guttman <uri@stemsystems.com>
MD> wrote:
>> i wouldn't call it controversial or flame baiting. you can disagree with
>> it but most style guides (PBP included) recommend named variables
>> whenever possible. sure it is a style issue but i am a strong advocate
>> of named variables as part of an overall style. and i emphasize choosing
>> quality names which makes it work even better.
MD> Well, PBP (and Perl::Critic) is somewhat controversial too. Some
MD> knowledgeable and respectful Perl hackers beg to differ on some
MD> specific points.
i was one of the tech editors of PBP and i disagree with many
points. but i do agree on using names vars where possible (some
exceptions do apply). damian explicitly states that PBP is meant to be a
possible set of rules and not an absolute set. you can pick and choose
and make up your own but consistancy in style is the goal, not a
particular style. and you should have at least a reason why any style
point is chosen and not some random default reason. good style has logic
behind it that defends it. i say named vars make the code more
readable as names help document what is being worked upon vs $_ which
has no such benefit. $_ can be set far enough away as to make it harder
to track its meaning. it can also cause action at a distance as it is a
global (though it can be localized by for or explicitly). just having
named vars be lexicals is a win too.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 09 Feb 2007 15:17:29 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Multiple Classes per File and use
Message-Id: <s40ps2dlp5us1f2ejrqn749q95q3keam0f@4ax.com>
On Thu, 08 Feb 2007 21:32:34 -0500, Uri Guttman <uri@stemsystems.com>
wrote:
>point is chosen and not some random default reason. good style has logic
>behind it that defends it. i say named vars make the code more
Agreed.
>readable as names help document what is being worked upon vs $_ which
>has no such benefit. $_ can be set far enough away as to make it harder
>to track its meaning. it can also cause action at a distance as it is a
>global (though it can be localized by for or explicitly). just having
>named vars be lexicals is a win too.
$_ is much like "it" in English. We use "it" all the time. We don't
use it to refer to something we said 20 minutes ago. We use an
explicit name when an explicit name is required. We use a pronuoun
when it is convenient and doesn't harm clarity. In Perl, it's not
that different, IMHO.
BTW: bleedperl provides a lexical $_ IIRC, but I'm not really sure
about the mechanism. I don't have a copy installed here. (Actually I'm
leaving, and I will most probably be offline for two or three days.)
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Tue, 06 Feb 2007 18:40:48 -0800
From: Xiong Changnian <please@nospam.net>
Subject: Re: Multiple Classes per File...
Message-Id: <please-FC15CD.18404806022007@free.teranews.com>
In article <Xns98CF996514C0Casu1cornelledu@127.0.0.1>,
"A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote:
> You are sounding cranky and stubborn...
I'm really very sorry if it appears that way to you. I *am* a cranky,
stubborn old man but I try not to act that way in every circumstance.
If I qualify the module with Jam::Band in package, use, and use base, it
works. I didn't see why, *instead*, as I've been doing, I can sometimes
call it merely Band.
My explanation is that use refers to the file itself, so needs the
directory relative to my script; use base and package refer to the
package/class instead and require no such qualification.
It makes sense, then, that I was able to declare packages/classes Tuba,
Drum, and Violin all in the file Guts.pm. I use Jam::Guts because there
is no file Jam::Tuba. I might (somewhere) use base qw(Tuba Drum Violin)
if for some mad reason, I want to inherit Moog from all three mommies.
If this isn't so, no matter; the vehicle takes me where I want to go and
my elbow is comfortably removed from the big red button. I'm entirely
satisfied with the answers I was given.
Thanks again for the suggestions.
--
Xiong Changnian
xiong102ATxuefangDOTcom
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Wed, 07 Feb 2007 16:20:29 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Multiple Classes per File...
Message-Id: <x7d54l7jhe.fsf@mail.sysarch.com>
>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:
XC> In article <Xns98CF996514C0Casu1cornelledu@127.0.0.1>,
XC> "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote:
>> You are sounding cranky and stubborn...
XC> I'm really very sorry if it appears that way to you. I *am* a cranky,
XC> stubborn old man but I try not to act that way in every circumstance.
XC> If I qualify the module with Jam::Band in package, use, and use base, it
XC> works. I didn't see why, *instead*, as I've been doing, I can sometimes
XC> call it merely Band.
XC> My explanation is that use refers to the file itself, so needs the
XC> directory relative to my script; use base and package refer to the
XC> package/class instead and require no such qualification.
you don't understand use, package names and modules yet. i will try to
explain them better. first off, the argument to use, a package name and
a module name/path are officially unrelated. you can use any value in
any of those places if you know what you are doing. there are ways they
are related and with conventions too and if you take advantage of them
they work well together.
package command name is just the default symbol table space for all the
code that follows it until the next package command or the end of the
file/eval block. this means you can put the same package name in
multiple modules and multiple package names in one module. a package
command has no other purpose but to set the default name for unqualified
globals. if you fully qualify all globals in use you would never need a
package command.
a module name (really just a file name) is just that, the name of a
physical module or file. it has nothing official to do with its contents
or any package names inside the file. the module name is just used to
locate and load a particular source file with a .pm suffix (i am
ignoring .so and related c libs here). if a module name is in some
subdirs like Foo/Bar/Util.pm those directories are not part of the
file name but need to be used to find the module.
a require command will take a class name Foo::Bar::Util and break up the
:: parts and convert the names into file system specific dirs, searches
OINC for it, opens that file (it adds a .pm suffix) if found and loads
it into perl. this is done at runtime and no symbol table munging
(exporting) is done for you. the module itself can do what it wants in
mainline code which will run then. require is executed at runtime so it
is good for loading modules on demand but not for loading symbols you
need in the current code.
a use command is a combination of a require and a call to the import
method. here is where things get interesting with module names and
package names. use does the same lookup of the file as require (note
that this can be case insensitive on some file systems which is a
classic newbie bug) and loads the file. but then it will take the class
name it was passed and call the class method import and pass it any
other args on the use line. in the common OO case, no import is found
since you don't export methods or symbols in pure OO. in typical
procedural modules some form of Exporter (there are a few now) will be
inherited and have an import method which gets called. it locates the
@EXPORT/_OK and related variables in your package and exports symbols
into the package with the use line as requested. note that it calls
import on ONLY one name, the class name passed to use. if you have more
than one package name in a module and one of them is the same class name
as called by use, only that package's import (usually inherited as i
said but it can be an explicit sub) is called. this is where some get
confused about multiple package names in a module and things not being
exported as expected.
finally we come to use base. base.pm is a simple pragma that saves a
little work when using inherited classes. it does two things, it loads
the requested module (but not with use which is fine as this is meant
for pure OO modules) and it also unshifts the classname into the current
package's @ISA (which controls method lookups for inheritance). so the
module name and class name when you do use base must agree if you want
the proper file to be loaded and to properly inherit from it. you can't
just pick names that seem right and do use base and it will work. your
case seems to be like that, you didn't make sure the module path and the
class names agreed when you did use base. in your case with all those
classes in one file and they all inherit from the same set, it would be
cleaner to just to a use at the top of the file and do this inside each
package:
# top of file and one time only. loads the file once which is all that
# is needed.
use Parent::Classes ;
# do this for each package in the file as needed
# doesn't load any files but sets up inheritance any way you want.
# note that the parent name isn't the same as the file loaded as i
# wanted to show how they can be different
package My::Foo ;
BEGIN{ our @ISA ; unshift 'Parent::Class::Foo, @ISA }
note that the use line can specify ANY module it wants and you can then
inherit separately in each class in the file. use base won't allow this
separation but it is designed for the common case where the package
names and files agree.
XC> It makes sense, then, that I was able to declare packages/classes
XC> Tuba, Drum, and Violin all in the file Guts.pm. I use Jam::Guts
XC> because there is no file Jam::Tuba. I might (somewhere) use base
XC> qw(Tuba Drum Violin) if for some mad reason, I want to inherit
XC> Moog from all three mommies.
i don't exactly get that but i think you should understand my explanation
above. you need to understand how these names and calls relate to each
other and not guess and thrash about.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 111
**************************************
