DZ-Jay wrote:
On Jan 7, 2006, at 03:49, Lyle Kopnicky wrote:
Doesn't that just let me import the methods of the class into my own
namespace, from another file? That would be weird - they're supposed
to be methods of a class. They belong in the class' namespace, not
mine.
They won't be imported unless you explicitly allow it (by using
Exporter, etc). What you are calling a "module" is merely a package
in its own file. When using Perl classes, a 'module' and a 'package'
are pretty much interchangeble.
Well, that's what I have right now. Two packages, each in their own
file. Each one is a class. But they are '.pl' files. Is there any
reason to make them '.pm' files? I don't see why I would want to export
anything from them.
You should read up on how Perl uses modules, packages and classes in
the perldoc.
I have read that, thanks. It seems like more trouble than it's worth to
make it them modules. For example, right now I have the class
TicketQueue in 'server/V-Res-TicketQueue.pl' and TicketSubQueue in
'server/V-Res-TicketSubQueue.pl'. In 'server/V-Res.pl', I have the line:
require 'server/V-Res-TicketQueue.pl';
The 'server/' path is necessary, since it's relative to the current
directory, not the location of 'V-Res.pl'. Then, within
'V-Res-TicketQueue.pl', I have:
require 'server/V-Res-TicketSubQueue.pl';
So, how would I make these into modules? Suppose I just rename them
with '.pm' extensions. Then, In 'server/V-Res.pl', I could write:
require 'server/V-Res-TicketQueue.pm';
And what would that buy me? Could I write:
use server::V-Res-TicketQueue;
? I don't think so. It woudn't like the dashes in the name, or the
lowercase name for 'server', and it wouldn't match the package name,
which is just TicketQueue.
I could add the 'server' folder to @INC. Then I still couldn't write:
user V-Res-TicketQueue;
because it wouldn't like the dashes. Perhaps I could rename the file to
just 'TicketQueue.pm'. Or I could make a VRes folder, then put
'TicketQueue.pm' inside of it? Then I'd have to change the package name
to VRes::TicketQueue.
Why go through all these hijinks? I still don't see what I'm getting
out of this. Why not just leave things the way they are?
For library modules, that have top-level utility subroutines, I can
understand making it a module. But for a class, it doesn't seem to make
sense. There's no need to export anything, since you can access methods
through the objects. Just a package-in-a-file seems to work just fine.
FYI, I'm only using the TicketQueue class from 'V-Res.pl', and only
using TicketSubQueue from 'V-Res-TicketQueue.pl'. So reuse isn't really
an issue.
Thanks.
--
Lyle Kopnicky
Software Project Engineer
Veicon Technology, Inc.
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
