using module

[ela]

Somebody has already written a module called abc.pm wherein subroutine def
is to invoke from my main program.

I'd appreciate an example of the necessary lines because errors like "method
cannot be found" keep appearing...

in abc.pm, do I need "require Export"?

in main.pl, should I write "use abc" and then "abc::def"?

 

[Rainer Weikusat]

Somebody has already written a module called abc.pm wherein subroutine def
is to invoke from my main program.

I'd appreciate an example of the necessary lines because errors like "method
cannot be found" keep appearing...

If it is really 'method', that would mean that you are trying to
invoke a subroutine via 'OO syntax', CLASS->method() or $obj->method()
and this method doesn't exist.

in abc.pm, do I need "require Export"?

in main.pl, should I write "use abc" and then "abc::def"?

The standard boilerplate (ignoring any attempts at covering the
mechanics of the Perl object model with "syntactic molasses" because it
looks so .... DIFFERENT !!1 [*]).

in the module (assuming it is not supposed to be used as a class)

package abc;

require Exporter; # ensure that Exporter is there
our @ISA = qw(Exporter); # declare that it's a superclass
our @EXPORT_OK = qw(sub1 sub2 sub2) # list exportable subroutines

in the 'other file using it':

use abc qw(sub2 sub3); # list of actually imported subs

[*] This is actually one of these rare strokes of genius, as nicely
exemplified by the fact that about everyone and his dog has been able
to hush it up in order to make his favority pet language look better in
comparison in a different way for more than a decade.

 

[Rainer Weikusat]

Inheriting from Exporter is no longer best practice.
Non-ancient versions of Exporter (5.57, with perl 5.8.3) will export
'import', so you can say

use Exporter "import";

instead and avoid inheriting a whole lot of random internal Exporter
methods you didn't want.

This would be more appropriately reworded as "I [meaning, you] (and
presumably some set of other people [who summarily confused enough
that they think that 'modern', whose actual meaning is 'currently
fashionable', would be 'surely positive enough' to make any actual
argument in favor of such an opinion redundant]) happen to be of the
opinion that this shouldn't be done".

And my reply to that would be: It's documented and it works and I've
been using it in this way since the times of perl 5.003. So what's the
compelling reason to change it?

[*] This is actually one of these rare strokes of genius, as nicely
exemplified by the fact that about everyone and his dog has been able
to hush it up in order to make his favority pet language look better in
comparison in a different way for more than a decade.

There are often sound reasons for setting up inheritance at compile
time,

Should I encounter one in code I write, I will consider doing so. But
this hasn't happened in the past sixteen odd years. OTOH, something
I've done fairly often is defining a set of related classes in a
single file, moving some or all of them to different files as the
code evolved and the classes became more complex. Or loading all
modules from some top-level file because of more complex
interdepedencies among them and just declaring inheritance
relationships in the modules.

 

[Rainer Weikusat]

[...]

I've been using it in this way since the times of perl 5.003. So
what's the compelling reason to change it?

Loosely related remark: I'm a content use of the Perl programming
language. I'm not the least of a fan of "download stuff from the
internet to get shit done fast" since I don't do "shit".

 

[Rainer Weikusat]

Quoth Rainer Weikusat <[email protected]>:
[...]

I am inclined to agree that I find chromatic et al.'s use of 'Modern
Perl' to mean 'Perl written according to current best practices; more
generally Perl treated as a serious programming language rather than a
quick hack' a bit trite,

And what I find more than 'a bit trite' is this 'opinion
marketing'. "Serious" and "how I would have done it" are two very much
different things.

I'm going to ignore the rest of this since you are just repeating
yourself.

 

[Rainer Weikusat]

[use Exporter "import" vs inheriting]

Loosely related remark: I'm a content use of the Perl programming ed ^^ ^^ r
language. I'm not the least of a fan of "download stuff from the
internet to get shit done fast" since I don't do "shit".

How *entirely* fascinating.

What does that have to do with Exporter?

For sake of completeness: This was supposed to communicate that I
generally don't use 'Perl modules' except if using them provides some
kind of signifcant benefit. And 'you must do as I bid you to do,
otherwise, be prepared to face the nameless horror!' is not something
I consider to be a valid argument in favor of 'significant benefit'.
Actually, I think it's rather an argument against that: If there is a
signifcant benefit, why not just name it when being asked for it?

 

[ela]

Dear Tad McClellan,

Posting codes definitely represents the most clearestly. However, when the
modules have copyright issues, the problem becomes more complex as that
means I have to extract the content carefully, which is not always easy -
and that also explains why I cannot always post the codes in my post.

Sometimes I just need a better explanation about a concept. In this case, I
go to check out Perl bibles, Perl 21 days, Perl beginners, etc, and then
surf the web, but the resources just put the concept so complexly. Rainer
Weikusat indeed solves my problem.

I don't want to challenge the rules of this newsgroup and therefore I'd
appreciate your advice when my problem is like this one.

Best regards,
Ela

 

[Jon Du Kim]

Oh, yes, the frequently posted but never read "Posting Guidelines".
Keep attacking those windmills!

 

[Jon Du Kim]

I'm sorry. I couldn't help but respond to the guidelines troll.
I'll do better in the future.