On Tuesday, April 9, 2002, at 11:13 , Jenda Krynicky wrote:
[..]
> So if a module defines several classes it has to contain several
> packages.
>
> Jenda
yes.... I think I would modify that slightly
it is simpler to deliver one long file as a singular 'package'
that carries with it all the class specifications
This makes more sense in an OO model - than in using PM's
to export 'global variables' and 'functions' - in the standard
proceduralist model - where having the simpler one package one file!
for those who would like a specific case - the following is the
stripped down illustration from an extension set we used to create
solaris sys V. packages from the build system.... One file, many
classes, each decending package declaration self referencing the
'mother ship' class....
package Project::dtk;
BEGIN { .... }
#--------
# PACKAGE ShellLib
#
# USAGE: new ShellLib('script_name', %arg)
#
package ShellLib;
use Project::dtk;
sub new($$;$) {...}
sub solaris_package_prototype_info($$$$$) {...}
#--------
package ShellConf;
use Project::dtk;
sub new($$;$) {...}
....
#--------
package WarpInit;
use Project::dtk;
.......
this allowed folks to do thing like
use Project::dtk;
....
foreach $name (@TheList)
{
push @products, new ShellLib ( $name ,
Class => 'application' );
}
.......
each 'sub package' of the main package required, at the time,
it may not now, that we reference that we get through use Project::dtk;
as you will note, those are WAY OLD style 'sub' routine predeclarations
now a way deprecated solution for all the reasons outlined in the
3rd edition..
this way we could 'sell' an OO style solution without having
to get folks to cut over to the OO style solution in what they
were working with - gosh isn't Perl Dangerous Like that.
{ actually I did that module without KNOWING that it was an
OO solution when I started... }
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
