[28872] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 116 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 9 23:06:17 2007

Date: Fri, 9 Feb 2007 20:05:43 -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: 116

Today's topics:
        OO Perl Online Learning <please@nospam.net>
    Re: OO Perl Online Learning <sbryce@scottbryce.com>
    Re: OO Perl Online Learning <cwilbur@chromatico.net>
    Re: OO Perl Online Learning <john@castleamber.com>
    Re: OO Perl Online Learning <segraves_f13@mindspring.com>
    Re: OO Perl Online Learning xhoster@gmail.com
    Re: OO Perl Online Learning <hjp-usenet2@hjp.at>
    Re: OO Perl Online Learning <please@nospam.net>
    Re: OO Perl Online Learning <cwilbur@chromatico.net>
    Re: OO Perl Online Learning <uri@stemsystems.com>
        p-value <ilpavox@gmail.com>
    Re: p-value <ilpavox@gmail.com>
    Re: p-value <jgibson@mail.arc.nasa.gov>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Mon, 05 Feb 2007 09:15:48 -0800
From: Xiong Changnian <please@nospam.net>
Subject: OO Perl Online Learning
Message-Id: <please-301246.09154805022007@free.teranews.com>

I've browsed my fingers off, read all the obvious sources and quite a 
few that are off-topic for my needs. I've even been to the local 
computer bookstore; there are many books on OO Perl, each with a hefty 
price tag. I'm not cheap; I'm broke. 

There seems to be little online between perltoot and the like; and 
highly specific discussions that assume advanced knowledge and dive into 
esoterics. I don't see the bridge -- general intermediate discussion of 
OO Perl. 

Here are the kinds of questions I've been trying to answer for myself: 

* What is all this about makefiles and installation? Why isn't it enough 
to download a module and un-tar it to my lib directory? Perhaps I'm 
handicapped, running MacPerl under OS 9. I haven't been able to install 
anything I've downloaded, not even stuff that shouldn't have anything to 
do with the Mac file system. 

* All the CPAN modules seem to be just one class per module; every 
source I've read says you *can* declare more than one package in a file 
but it seems that in practice, it's one class, one package, one module, 
one file. Yet I'm contemplating a set of perhaps 20 closely related 
classes. I don't know if I'm taking the wrong approach or if there's a 
way to bundle them neatly. And yes, I've read a little on CPAN bundles; 
I'm still in the dark. I suspect this question ties into the last. 

* The *use* pragma makes a class available in a given file but doesn't 
seem to propagate; I have to *use* the class everywhere I, well, use it. 
Is there no single place I can declare an entire set of classes for use 
in any script that *uses* that file? This obviously ties into the last. 

* Same question, different angle: If I *use* and inherit among a group 
of classes, it seems I run into dependency problems. Is this a lack of 
clear thinking on my part and I need to draw up a strict table of 
dependencies and work out the order in which the compiler sees 
declarations? Or can I just throw everything in if I declare them the 
"right" way? 

* What's all this about test suites? I can understand writing a script 
that stands on its own and exercises a module. I see discussions that 
look as though these test scripts are being generated automatically in 
some way. 

* Should I *always* use strict and use warn? I've been doing just that, 
beating the code until it works under these conditions. I see a lot of 
code online that shouldn't, though. Right now, I'm using symbolic refs 
in one place and I feel I oughtn't. 

Nobody has to take the time to answer any of these questions *here* but 
I'd love a pointer or five. 

Xiong
-- 
Xiong Changnian
xiong102ATxuefangDOTcom

-- 
Posted via a free Usenet account from http://www.teranews.com



------------------------------

Date: Mon, 05 Feb 2007 10:43:41 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: OO Perl Online Learning
Message-Id: <XImdnUPv2t5f8VrYnZ2dnUVZ_uWlnZ2d@comcast.com>

Xiong Changnian wrote:

> I've browsed my fingers off, read all the obvious sources and quite a 
> few that are off-topic for my needs. I've even been to the local 
> computer bookstore; there are many books on OO Perl, each with a hefty 
> price tag. I'm not cheap; I'm broke. 

The public library is your friend.  My local library has a copy of 
Damian Conway's Object Oriented Perl.


------------------------------

Date: 05 Feb 2007 13:10:41 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: OO Perl Online Learning
Message-Id: <87zm7spja6.fsf@mithril.chromatico.net>

>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:

    XC> * What is all this about makefiles and installation? Why isn't
    XC> it enough to download a module and un-tar it to my lib
    XC> directory? Perhaps I'm handicapped, running MacPerl under OS
    XC> 9. I haven't been able to install anything I've downloaded,
    XC> not even stuff that shouldn't have anything to do with the Mac
    XC> file system.

First off, you are indeed handicapped by running MacPerl under OS 9.  

It isn't enough to simply download a module and un-tar it because a
number of other files may need to be changed.  The module installation
process also includes ensuring the module is as packaged, that all
prerequisites are in place, and that all necessary files (such as
those used to generate perldoc perllocal) are updated.  Some modules
also have stubs to link to C libraries, which require a C compiler.
Because Perl was conceived on Unix, the most obvious way to manage all
this was with Makefiles.

On platforms that don't include compilers and Makefiles, alternative
approaches have been developed, from BSD ports and packages to
ActiveState Perl package repositories.  Unfortunately for you, OS 9 is
neither Unixlike nor actively supported, which means you're out of luck.

If you insist on not upgrading to OS X, you might consider getting an
external drive and installing one of the PPC Linuxes on it.  If you
insist on remaining on OS 9, you need to prepare yourself for a lot of
frustration and annoyance.

    XC> * What's all this about test suites? I can understand writing
    XC> a script that stands on its own and exercises a module. I see
    XC> discussions that look as though these test scripts are being
    XC> generated automatically in some way.

They aren't necessarily generated automatically, but if you conform
with the behavior expected by Test::Simple and its relatives, you can
run them automatically during development and run them automatically
at installation time.

    XC> * Should I *always* use strict and use warn? I've been doing
    XC> just that, beating the code until it works under these
    XC> conditions. I see a lot of code online that shouldn't,
    XC> though. Right now, I'm using symbolic refs in one place and I
    XC> feel I oughtn't.

Yes, you should *always* use strictures and warnings, especially as
they're both scoped, and when you need to do something that violates a
stricture or warning, you can turn that diagnostic off in the smallest
possible scope.  Even then, there's almost always a better way.

    XC> Nobody has to take the time to answer any of these questions
    XC> *here* but I'd love a pointer or five.

As to your questions about OO syntax and inheritance --
_Object-Oriented Perl_, by Damian Conway.  Good luck.

Charlton


-- 
Charlton Wilbur
cwilbur@chromatico.net


------------------------------

Date: 5 Feb 2007 18:47:45 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: OO Perl Online Learning
Message-Id: <Xns98CE822A7254castleamber@130.133.1.4>

Xiong Changnian <please@nospam.net> wrote:
 
> * All the CPAN modules seem to be just one class per module;

I can confirm that this is /not/ true. Just grep for package over all pm 
files and I am sure you will find modules already installed that have more 
then one class per pm file.

> one file. Yet I'm contemplating a set of perhaps 20 closely related 
> classes.

Unless they are very short (linewise) you might be better of to put each 
in a file of their own. Or a combination. 20 classes in one file is IMO a 
pain in the ass to edit, even if you can split your window in 2 or more 
views.

> * Should I *always* use strict and use warn? I've been doing just that, 
> beating the code until it works under these conditions. I see a lot of 
> code online that shouldn't, though. Right now, I'm using symbolic refs 
> in one place and I feel I oughtn't. 

Show the code. The nice thing of use warnings is that you can disable 
warnings for a block.

-- 
John                Experienced Perl programmer: http://castleamber.com/

          Perl help, tutorials, and examples: http://johnbokma.com/perl/


------------------------------

Date: Mon, 05 Feb 2007 19:30:31 GMT
From: "Bill Segraves" <segraves_f13@mindspring.com>
Subject: Re: OO Perl Online Learning
Message-Id: <rBLxh.19000$pQ3.7954@newsread4.news.pas.earthlink.net>

"Xiong Changnian" <please@nospam.net> wrote in message
news:please-301246.09154805022007@free.teranews.com...
> I've browsed my fingers off, read all the obvious sources and quite a
> few that are off-topic for my needs. I've even been to the local
> computer bookstore; there are many books on OO Perl, each with a hefty
> price tag. I'm not cheap; I'm broke.

http://www.manning.com/conway/

Damian Conway's _Object Oriented Perl_, $21.50 for the PDF ebook, is
significantly less expensive than the print editions you'll find in book
stores.

I think you'll find that the ebook, together with online access to the
Author Forum and Source Code, will be a good investment for you.

Cheers,

--
Bill Segraves




------------------------------

Date: 05 Feb 2007 20:08:02 GMT
From: xhoster@gmail.com
Subject: Re: OO Perl Online Learning
Message-Id: <20070205150844.839$mF@newsreader.com>

Xiong Changnian <please@nospam.net> wrote:
> I've browsed my fingers off, read all the obvious sources and quite a
> few that are off-topic for my needs. I've even been to the local
> computer bookstore; there are many books on OO Perl, each with a hefty
> price tag. I'm not cheap; I'm broke.
>
> There seems to be little online between perltoot and the like;

By "the like", do you mean  perlobj, perlboot, perltooc, perlmod and
perlbot?

> and
> highly specific discussions that assume advanced knowledge and dive into
> esoterics. I don't see the bridge -- general intermediate discussion of
> OO Perl.
>
> Here are the kinds of questions I've been trying to answer for myself:
>
> * What is all this about makefiles and installation? Why isn't it enough
> to download a module and un-tar it to my lib directory?

Usually it is.  If it isn't, it could be that the module is not pure Perl
but has XS code that needs to be compiled, or it is dependent on other
modules which you don't have installed.


> * All the CPAN modules seem to be just one class per module;

Look at more modules.  Tie::File, for example, has two helper classes.
And that is not unusual.  Running:

egrep -rc '^package' $PERL5LIB | awk -F: '$2>1 {print $1}'

Should point out some more candidates for having more than one class per
file.

> every
> source I've read says you *can* declare more than one package in a file
> but it seems that in practice, it's one class, one package, one module,
> one file. Yet I'm contemplating a set of perhaps 20 closely related
> classes. I don't know if I'm taking the wrong approach or if there's a
> way to bundle them neatly.

You just put all the code in one file with multiple package statements.
Unless you need to import stuff, there should be no problem.


> * The *use* pragma makes a class available in a given file but doesn't
> seem to propagate;

Could you give an example?  I've not had this problem with OO modules.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB


------------------------------

Date: Mon, 5 Feb 2007 21:47:52 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: OO Perl Online Learning
Message-Id: <slrnesf5vo.i27.hjp-usenet2@yoyo.hjp.at>

On 2007-02-05 17:15, Xiong Changnian <please@nospam.net> wrote:
> * What is all this about makefiles and installation? Why isn't it enough 
> to download a module and un-tar it to my lib directory?

If it's a pure perl module, that will work. However, as Charlton already
mentioned, some modules are not pure perl, and the installation process
also checks dependencies and does some bookkeeping. 

There is another important point: Testing. 

By downloading the module into one directory and then installing it you
can test a module before you install it (and possibly overwrite a
working version with a non-working version). Most Modules on CPAN come
with a test-suite. If you run "make test" before "make install" (cpan
will do that automatically), you can be reasonably sure that the module
will work as expected on your system (which is even more important if
you run a relatively exotic system like MacOS 9 - you do need a "make"
command, though. Only a few distributions use Module::Build instead of
Makemaker).



> * All the CPAN modules seem to be just one class per module;

Nope. There are quite a few which have more than one class/package per
file.

> every source I've read says you *can* declare more than one package in
> a file but it seems that in practice, it's one class, one package, one
> module, one file.

Putting several packages into a single file is generally less clear, and
you can't "use" a package if the filename can't be derived from the
package name - so all your "public" packages must be in a file of their
own. "Private" packages which aren't supposed to be "use"d by the
programmer are sometimes put into the same file as the package which
uses them.

> Yet I'm contemplating a set of perhaps 20 closely related classes. I
> don't know if I'm taking the wrong approach or if there's a way to
> bundle them neatly. And yes, I've read a little on CPAN bundles; 

No need to bundle them. If they are closely related, put them into the
same distribution.


> * The *use* pragma makes a class available in a given file but doesn't 
> seem to propagate; I have to *use* the class everywhere I, well, use it. 

Not quite. You only need to "use" the class where you need to import
its symbols, and obviously you need to load the module to use any code
in it, so you need to "use" (or require, do, whatever) it somewhere.

But you can use objects of classes and even class methods of packages
which you didn't use directly. For example, in

    use MIME::Parser;

    my $parser = new MIME::Parser();
    my $entity = $parser->parse(\*STDIN);
    my $head = $entity->head();

$entity is an object of the class MIME::Entity, and $head is a
MIME::Head. You don't need to "use" these modules to use these objects.
MIME::Parser "use"s them, and that's sufficient.


> * Same question, different angle: If I *use* and inherit among a group 
> of classes, it seems I run into dependency problems. Is this a lack of 
> clear thinking on my part and I need to draw up a strict table of 
> dependencies and work out the order in which the compiler sees 
> declarations? Or can I just throw everything in if I declare them the 
> "right" way? 

Inheritance is a bit of a sore spot in perl. It depends on how the
classes you want to inherit from are written.


> * What's all this about test suites?

They help you find bugs.

> I can understand writing a script that stands on its own and exercises
> a module.

A test suite is a collection of such scripts. 

> I see discussions that look as though these test scripts are being
> generated automatically in some way. 

No, they aren't (normally) *generated* automatically. You need to write
them yourself, and that often takes as much thought as writing the
actual code (unless your specification is already very detailed and
formal, in that (rare) case, a test-suite can be genereted from the spec
(semi-)automatically). However, the test suite is *run* every time you
type "make test" and every time someone installs the distribution via
CPAN. So errors which are covered by a test-case will be found soon.

	hp


-- 
   _  | Peter J. Holzer    | Es ist ganz einfach ihn zu verstehen, wenn
|_|_) | Sysadmin WSR       | man nur alle wichtigen Worte im Satz durch
| |   | hjp@hjp.at         | andere ersetzt.
__/   | http://www.hjp.at/ |	-- Nils Ketelsen in danr


------------------------------

Date: Mon, 05 Feb 2007 13:04:55 -0800
From: Xiong Changnian <please@nospam.net>
Subject: Re: OO Perl Online Learning
Message-Id: <please-4B2DF0.13045505022007@free.teranews.com>

In article <87zm7spja6.fsf@mithril.chromatico.net>,
 Charlton Wilbur <cwilbur@chromatico.net> wrote:

> If you insist on not upgrading to OS X, you might consider getting an
> external drive and installing one of the PPC Linuxes on it.  If you
> insist on remaining on OS 9, you need to prepare yourself for a lot of
> frustration and annoyance.

It's difficult to explain why I still run OS 9 and I'm not sure this is 
the place for it. Assume all the reasons given by bad managers for 
legacy systems and stir in a large helping of poverty. Fact is, I've got 
my beige G3 hot-rodded, hardware and software, to an impressive extent. 
It works -- most of the time -- very well. 

I tried, over a period of about six months, to install various flavors 
of Linux on a beige Mac. It was a nightmare. I think the way out of my 
corner is to wait until I have enough workspace to set up two 
workstations, buy a cheap Intel box and put a standard Linux distro on 
it -- never touch windoz -- and go back and forth between the two 
systems until I make the transition. Even then, I anticipate a PowerBook 
for years to come. There is simply no reasonable way, in some cases, to 
convert old work files. 

> if you conform
> with the behavior expected by Test::Simple...

I have plain Test installed and I looked over the POD before I posted 
here. It assumes I already know what the author is driving at. I'll 
exercise it a bit and see what happens. I'm afraid I'm not really an 
experimentalist at heart; I like to read the manual. I've been looking 
at a number of files shipped with MacPerl with the extension .t as well. 
I suspect I will learn something. 


In article <XImdnUPv2t5f8VrYnZ2dnUVZ_uWlnZ2d@comcast.com>,
 Scott Bryce <sbryce@scottbryce.com> wrote:

> The public library is your friend.  My local library has a copy of 
> Damian Conway's Object Oriented Perl.

I should have thought of that. This *is* San Jose. Even $21.50 for the 
PDF is too rich for my blood. 


In article <Xns98CE822A7254castleamber@130.133.1.4>,
 John Bokma <john@castleamber.com> wrote:

> Just grep for package over all pm 
> files and I am sure you will find modules already installed that have more 
> then one class per pm file.

I've been looking for such examples; I'll look harder. 

> Unless they are very short (linewise) you might be better of to put each 
> in a file of their own. Or a combination. 20 classes in one file is IMO a 
> pain in the ass to edit, even if you can split your window in 2 or more 
> views.

You're right, of course. But 20 files is also a kind of pain. I think a 
balanced hierarchy would be something like 5 distinct files, one each 
for important, complex classes; plus another 2 or 3 files containing 
these itty-bitty classes that have only perhaps 2 methods each. 

> Show the code. The nice thing of use warnings is that you can disable 
> warnings for a block.

I posted that before. Here again: 

    sub report_sets {
        my @keys = sort keys %{ $ref->{SETS} };        
        foreach (@keys) {
            &{"report_" . lc($_)} ($ref->{SETS}{$_}) 
                    or die ("No report subroutine for $_.");
        };
    };

Many such subs, one for each hash key; some actually do something. 
Symbolic ref, so I bracket this with no strict "refs";  

It *does* work but I'm pretty sure there *is* a better way; I just have 
to make every hash level an object -- which leads to a proliferation of 
"internal" classes, most obviously named after the hash keys which 
invoke them. Thus my worries about -- "bundle bloat"? 


In article <20070205150844.839$mF@newsreader.com>, xhoster@gmail.com 
wrote:

> By "the like", do you mean  perlobj, perlboot, perltooc, perlmod and
> perlbot?

Yes, Sir, I believe I've read them all three to seven times. They're 
pretty basic. There may still be stuff to be gleaned from them but I 
look forward to paging through Conway. 

> > * All the CPAN modules seem to be just one class per module;
> 
> Look at more modules.  Tie::File, for example, has two helper classes.
> And that is not unusual. 

I don't have Tie::File handy but I'm just now looking over Tie::Array, 
which has in the file both package Tie::Array and package Tie::StdArray; 
and I will study this until I see how it works. Good tip. 

> > * The *use* pragma makes a class available in a given file but doesn't
> > seem to propagate;
> 
> Could you give an example? 

I'd better put a lengthy code example in another post. First, I want to 
strip out all possible dead wood. Thanks for the invitation. 

And many thanks to all for the extensive help. 

Xiong
-- 
Xiong Changnian
xiong102ATxuefangDOTcom

-- 
Posted via a free Usenet account from http://www.teranews.com



------------------------------

Date: 05 Feb 2007 16:43:54 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: OO Perl Online Learning
Message-Id: <87mz3sp9et.fsf@mithril.chromatico.net>

>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:

    XC> In article <87zm7spja6.fsf@mithril.chromatico.net>,
    XC>  Charlton Wilbur <cwilbur@chromatico.net> wrote:

    >> If you insist on not upgrading to OS X, you might consider
    >> getting an external drive and installing one of the PPC Linuxes
    >> on it.  If you insist on remaining on OS 9, you need to prepare
    >> yourself for a lot of frustration and annoyance.

    XC> It's difficult to explain why I still run OS 9 and I'm not
    XC> sure this is the place for it.

It doesn't matter, and it isn't.  What I said, I stand by; the fact
that you have very good reasons to remain on OS 9 will not alter the
frustration and annoyance.

Charlton



-- 
Charlton Wilbur
cwilbur@chromatico.net


------------------------------

Date: Mon, 05 Feb 2007 17:21:58 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: OO Perl Online Learning
Message-Id: <x7k5yw9reh.fsf@mail.sysarch.com>

>>>>> "XC" == Xiong Changnian <please@nospam.net> writes:


  XC> In article <XImdnUPv2t5f8VrYnZ2dnUVZ_uWlnZ2d@comcast.com>,
  XC>  Scott Bryce <sbryce@scottbryce.com> wrote:

  >> The public library is your friend.  My local library has a copy of 
  >> Damian Conway's Object Oriented Perl.

  XC> I should have thought of that. This *is* San Jose. Even $21.50 for the 
  XC> PDF is too rich for my blood. 

it is old enough that there are many used copies out there. check amazon
and ebay for copies.

also beginning perl is online and free at learn.perl.org. i don't how
deep it gets into OO but it may help some

  XC> In article <Xns98CE822A7254castleamber@130.133.1.4>,
  XC>  John Bokma <john@castleamber.com> wrote:

  >> Just grep for package over all pm 
  >> files and I am sure you will find modules already installed that have more 
  >> then one class per pm file.

  XC> I've been looking for such examples; I'll look harder. 

  >> Unless they are very short (linewise) you might be better of to put each 
  >> in a file of their own. Or a combination. 20 classes in one file is IMO a 
  >> pain in the ass to edit, even if you can split your window in 2 or more 
  >> views.

  XC> You're right, of course. But 20 files is also a kind of pain. I think a 
  XC> balanced hierarchy would be something like 5 distinct files, one each 
  XC> for important, complex classes; plus another 2 or 3 files containing 
  XC> these itty-bitty classes that have only perhaps 2 methods each. 

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.

  XC> I posted that before. Here again: 

  XC>     sub report_sets {
  XC>         my @keys = sort keys %{ $ref->{SETS} };        
  XC>         foreach (@keys) {

use named variable when possible. it makes for more easily understood
code. 

  XC>             &{"report_" . lc($_)} ($ref->{SETS}{$_}) 

eww, that is symrefs. make a dispatch table and your code will be
cleaner and safer. google this group for 'dispatch table' and you will
find many threads on it.


  XC>                     or die ("No report subroutine for $_.");
you can't die that late. you already called the unknown sub. a dispatch
table will allow a check before calling which is what you want.

  XC>         };
  XC>     };

  XC> Many such subs, one for each hash key; some actually do something. 
  XC> Symbolic ref, so I bracket this with no strict "refs";  

bad boy! no cookie for you. dispatch tables are the best way to do that
and no symrefs are needed.

  XC> It *does* work but I'm pretty sure there *is* a better way; I just have 
  XC> to make every hash level an object -- which leads to a proliferation of 
  XC> "internal" classes, most obviously named after the hash keys which 
  XC> invoke them. Thus my worries about -- "bundle bloat"? 

you don't have to make every hash level an object. that is again the
java way and i doubt you need to do that here. too many objects is just
as bad as too few. objects are meant to help organized code and data,
not tag them to death like xml.

  XC> Yes, Sir, I believe I've read them all three to seven times. They're 
  XC> pretty basic. There may still be stuff to be gleaned from them but I 
  XC> look forward to paging through Conway. 

you need an eighth reading! :) OOP is a great book and you should beg
borrow or (well not really) steal a copy. used copies are your best bet
as i have said.

  >> > * The *use* pragma makes a class available in a given file but doesn't
  >> > seem to propagate;
  >> 
  >> Could you give an example? 

  XC> I'd better put a lengthy code example in another post. First, I want to 
  XC> strip out all possible dead wood. Thanks for the invitation. 

use does two things and you seem to be confusing them. one is to load a
module and that needs to be done only once (basically the same as
require but which loads at runtime). the other is to call the import
mathod of the class you loaded and that needs to be done in each file
that wants exported symbols. but if you are doing only OO in a module
and not exporting anything then it can be loaded once with use. again, i
suspect you are creating too many classes and may be crossing OO with
exported symbols which is not a good idea.

when you post more code it will be easier to help with the bigger design
issues i sense here. i smell an XY problem which means you picked a
solution X and are working hard but you really need solution Y.

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: 4 Feb 2007 20:00:45 -0800
From: "fed" <ilpavox@gmail.com>
Subject: p-value
Message-Id: <1170648045.449123.59410@v45g2000cwv.googlegroups.com>

I've been searching around for a module that will input 2 arrays and
output a p-value.  I've been using statistics::rankcorrelation but I
need to limit the output.  There has to be something out there.
anyone?  Thanks.



------------------------------

Date: 4 Feb 2007 20:01:47 -0800
From: "fed" <ilpavox@gmail.com>
Subject: Re: p-value
Message-Id: <1170648107.371972.270780@j27g2000cwj.googlegroups.com>

On Feb 4, 11:00 pm, "fed" <ilpa...@gmail.com> wrote:
> I've been searching around for a module that will input 2 arrays and
> output a p-value.  I've been using statistics::rankcorrelation but I
> need to limit the output.  There has to be something out there.
> anyone?  Thanks.

I didn't add that this is for spearman.  thanks



------------------------------

Date: Mon, 05 Feb 2007 12:09:52 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: p-value
Message-Id: <050220071209523665%jgibson@mail.arc.nasa.gov>

In article <1170648107.371972.270780@j27g2000cwj.googlegroups.com>, fed
<ilpavox@gmail.com> wrote:

> On Feb 4, 11:00 pm, "fed" <ilpa...@gmail.com> wrote:
> > I've been searching around for a module that will input 2 arrays and
> > output a p-value.  I've been using statistics::rankcorrelation but I
> > need to limit the output.  There has to be something out there.
> > anyone?  Thanks.
> 
> I didn't add that this is for spearman.  thanks
> 

Have you searched CPAN? <http://search.cpan.org>. I got some hits for
'p-value' and one (Statistics::RankCorrelation) for 'spearman'. Since I
don't know what these terms mean, I can't help further.

 Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------        
                http://www.usenet.com


------------------------------

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 116
**************************************


home help back first fref pref prev next nref lref last post