EXPORT and EXPORT_OK question

[T]

Hi All,

I am over on

http://www.thegeekstuff.com/2010/06/perl-exporter-examples/

reading how to create my own modules. It states

@EXPORT contains list of symbols (subroutines and variables)
of the module to be exported into the caller namespace.

@EXPORT_OK does export of symbols on demand basis.

Okay, why? Does not the Perl interpreter toss anything
not used?

Why would you not always use @EXPORT_OK? Often modules
have a lot of stuff in them that are not used by
the calling script. Seems that if you use @EXPORT that
everything gets loaded, used of not.

I don't get it.

-T

[Rainer Weikusat]

T <T...@invalid.invalid> writes:
> I am over on
>
> http://www.thegeekstuff.com/2010/06/perl-exporter-examples/
>
> reading how to create my own modules. It states
>
> @EXPORT contains list of symbols (subroutines and variables)
> of the module to be exported into the caller namespace.
>
> @EXPORT_OK does export of symbols on demand basis.
>
> Okay, why? Does not the Perl interpreter toss anything
> not used?
>
> Why would you not always use @EXPORT_OK?

I usually use @EXPORT for modules whose only purpose is to make a small
set of closely-related things available to the user, eg,

--------
# provide poll-related constants
#
# $Id: poll.pm,v 1.5 2012/09/04 20:06:22 rw Exp $
#

#* package
#
package MES::poll;

require Exporter;

our @ISA = qw(Exporter);
our @EXPORT = qw(POLLIN POLLOUT POLLHUP POLLERR);

#* constants
#
use constant POLLIN => 1;
use constant POLLOUT => 4;
use constant POLLERR => 8;
use constant POLLHUP => 0x10;

# Sachverwalter der Unendlichkeit
1;
--------

The only reason why some code would use this module is get access to the
POLL constants. These are the well-known names used by the corresponding
C interface and they're sufficiently strange so that accidental
collisions won't be an issue. And micro-manageing these four names is
IMHO not worth the effort.

[T]

Hi Rainer,

Made me look up "constants". It does not mean the same thing
as in Modula 2.

In the above, does "=>" not mean " equal to or greater than"?

Also, I still don't get why EXPORT and EXPORT_OK. Seems to
me the interpreter would toss what it doesn't use. Why do we
even need two of these?

Thank you for helping me with this. Loved the example and
am about to copy it down.

-T

[T]

On 07/24/2015 01:20 PM, Rainer Weikusat wrote:

> # Sachverwalter der Unendlichkeit

Please translate

> 1;

Why is this one hanging out here?

[George Mpouras]

On 25/7/2015 00:06, T wrote:
>
>> 1;
>
> Why is this one hanging out here?

all packagers must return TRUE as last statement

[T]

Hi George,

is
1;

short for
return true;

-T

[T]

On 07/24/2015 02:09 PM, George Mpouras wrote:

Looking at the example over at
http://www.thegeekstuff.com/2010/06/perl-exporter-examples/

The code does not end in "1;". But each subroutine has
a "return" statement. Does Rainer's code have to have
a "1;" because there are no subs ending with "return"?

[Mart van de Wege]

Yes.

Like in Lisp, literals evaluate to themselves, and return that value. In
Perl, everything that is not 0, undef or the empty string is true.

Mart

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

[Mart van de Wege]

T <T...@invalid.invalid> writes:

> Hi All,
>
> I am over on
>
> http://www.thegeekstuff.com/2010/06/perl-exporter-examples/
>
> reading how to create my own modules. It states
>
> @EXPORT contains list of symbols (subroutines and variables)
> of the module to be exported into the caller namespace.
>
> @EXPORT_OK does export of symbols on demand basis.
>
> Okay, why? Does not the Perl interpreter toss anything
> not used?
>

No. The Perl interpreter will define symbols inside a package. Without
explicit export, these symbols will *only* be visible from inside the
package, or from outside using a fully qualified name.

Adding symbols to the @EXPORT array will export the unqualified names to
the importing scope. So if you 'use' a module in your main program, the
symbols in the @EXPORT array will be imported into your main program and
be usable without qualifying them. They will, however, overwrite other
symbols with the same name.

So if you want to define variables and subs that are only visible inside
their package and don't clash with symbols outside, then you don't
include them in the @EXPORT array.

This is how Object-Oriented packages work: they export nothing,
everything is only visible inside the package; the constructor function
is called by fully qualifying the package name, and it will return an
object that does have access to the package, but only through calling
methods on it (or by explicitly referencing the parent package, aka
class).

> Why would you not always use @EXPORT_OK?

Because sometimes you want to use symbols inside a package without the
outside world having default access to them; or you want to avoid symbol
clashes in the importing scope.

> Often modules have a lot of stuff in them that are not used by the
> calling script. Seems that if you use @EXPORT that everything gets
> loaded, used of not.

Everything always gets loaded. The @EXPORT defines what you can use
without having to fully qualify the symbols.

[Mart van de Wege]

Nope. In perl, the => operator is essentially a comma, you use it to
build lists.

This is equivalent:

my @array = (1,2,3);

my @array = (1 => 2 => 3);

(note that the parentheses are mandatory, without them a comma does
something different).

It's basically syntactic sugar to make hashes more readable. my %hash =
( key => value ) is identical to my %hash = ( key, value ); in fact a
hash will take any list with an even number of elements and use the
first element of every pair as a key and the second as the value; using
=> makes this more explicit.

[Mart van de Wege]

Legacy.

The 'use' statement must return true in order to successfully import a
module. Therefore the last statement in the module must return true; the
easiest way to do that is to add a literal 1 at the end.

[T]

Hi Mart,

I understood what you said, but am puzzled as to
why he did not just use

use constant POLLIN = 1;

without the ">"?

-T

[Mart van de Wege]

T <T...@invalid.invalid> writes:

> On 07/24/2015 02:42 PM, Mart van de Wege wrote:
>> T <T...@invalid.invalid> writes:
>>
>>> On 07/24/2015 01:20 PM, Rainer Weikusat wrote:

<snip>

>>>> #
>>>> use constant POLLIN => 1;
>>>> use constant POLLOUT => 4;
>>>> use constant POLLERR => 8;
>>>> use constant POLLHUP => 0x10;
>>>>
>>>> # Sachverwalter der Unendlichkeit
>>>> 1;
>>>> --------

<snip>

>
> Hi Mart,
>
> I understood what you said, but am puzzled as to
> why he did not just use
>
> use constant POLLIN = 1;
>
> without the ">"?
>

Probably because that is the syntax 'use constant' wants. I have not
looked into the syntax of this module, but on first sight it appears
that 'use constant' takes a two element list as argument, and using the
'fat comma' operator makes that more readable.

[T]

This is how Modula2 imports things:

FROM Terminal2 IMPORT WriteString, WriteCard, WriteLn;

You only import what you specify. Not a grab bag of functions.

Is Perl using EXPORT and EXPORT_OK in the module
to accomplish the same thing at interpret time?

[T]

Hi Mart,

Okay, in Modula2 you only got to see what was exported. In bash
script everything is global and visible everywhere (it is a pain
in the ...).

I guess my confusion is why would it be anything other that
what you described?

>> Why would you not always use @EXPORT_OK?
>
> Because sometimes you want to use symbols inside a package without the
> outside world having default access to them;

With me it is "all-the-time". I only want the outside world
to see what I explicitly export. I am tired to death of having
my scratch paper variables ("my" and "local" in Perl) getting blown
everywhere (in bash, everything is "our").

I can see "@EXPORT". But I still can not understand what
"@EXPORT_OK" is all about. I never, ever want the outside
world to see the inner workings of my exported modules.
I only want the outside world to see the result.

I just don't get "@EXPORT_OK" or what it is used for.

> or you want to avoid symbol
> clashes in the importing scope.
>
>> Often modules have a lot of stuff in them that are not used by the
>> calling script. Seems that if you use @EXPORT that everything gets
>> loaded, used of not.
>
> Everything always gets loaded. The @EXPORT defines what you can use
> without having to fully qualify the symbols.
>

Would you show me a quick example of a "fully qualified symbol"?

> Mart
>

Thank you for all your wonderful explanations.

-T

[Jim Gibson]

Perl offers the writer of a module to export everything by default
(@EXPORT) or to allow the explicit export of functions as needed by the
module user (@EXPORT_OK).

One of the philosophies of the Perl architects is to allow various
types of module access and not restrict to only one kind of access.

It is up to the author of the module to choose which type of access to
allow for the subroutines in his/her module.

--
Jim Gibson

[T]

On 07/24/2015 11:18 PM, Jim Gibson wrote:
> In article <moufoe$8rg$2...@dont-email.me>, <T...@invalid.invalid> wrote:
>
>> On 07/24/2015 01:08 PM, T wrote:
>
>>
>> This is how Modula2 imports things:
>>
>> FROM Terminal2 IMPORT WriteString, WriteCard, WriteLn;
>>
>> You only import what you specify. Not a grab bag of functions.
>>
>> Is Perl using EXPORT and EXPORT_OK in the module
>> to accomplish the same thing at interpret time?
>
> Perl offers the writer of a module to export everything by default
> (@EXPORT) or to allow the explicit export of functions as needed by the
> module user (@EXPORT_OK).

I can't tell them apart.

[$Bill]

On 7/24/2015 19:10, T wrote:
>
> I just don't get "@EXPORT_OK" or what it is used for.

use Module; # will import everything in @EXPORT in the module
# but nothing from @EXPORT_OK (unless there is some
# overlap - subs listed in both) - implicitly imports
# everything in @EXPORT.

use Module qw(SubA SubC); # will import 2 subs/etc from the module that are
# either in @EXPORT or @EXPORT_OK - a way to require
# you to explicitly import these names.

All subs/etc in @EXPORT are automatically imported.
All subs/etc in @EXPORT_OK have to be specifically asked for.

So @EXPORT_OK requires you to EXPLICITLY ask for that sub/etc thus
helping protect your namespace from a pile of unnecessary names.

[shar...@hotmail.com]

Whatever symbols(meaning, functions, variables) in the
@EXPORT array shall be visible in the place where it will be "use-d"
and whatever symbols are put in the @EXPORT_OK array will only
be available upon request. Specifically, let's say in a module the
module writer(NOT the module user) put this in the module's code:

@EXPORT = qw( f1 f2 f3 );
@EXPORT_OK = qw( g1 g2 g3 g4 g5);

N.B.:
print for @File::Basename::EXPORT; --> show me the auto-exported symbols
print for @File::Basename::EXPORT_OK; --> show me the asked-for symbols


Then, in your code where you use YourModule, the following 3 different ways

1. use YourModule; # Import default symbols into my package.
2. use YourModule qw(f2 g5); # Import listed symbols into my package.
3. use YourModule (); # Do not import any symbols

Method-1. All of contents of @EXPORT, i.e., f1 f2 f3 will appear in your code.

Method-2. Only f2 & g5 visible. Note: f1/f3 which are default DO NOT show up.

Method-3. Nothing shows up in your code. You have to resort to using the full
names, like , File::Basename::dirname with this method.

[Rainer Weikusat]

"That's something I'd very much like to know myself!"

The 'perl primitive' for reading executing a file with Perl code at
run-time is

do "/some/where/a.pl/was/found";

(argument is the name of the file, @INC-directories are searched)

This returns the value of the last expression evaluated while executing
the file. On top of this sits require which is - for loading modules -
usually used like this:

require Fast::Nilebame;

Provided the module wasn't already loaded, this will end up executing

do "Fast/Nilebame.pm"

to load a module file and if the value returned by this statement is not
considered 'true' (ie, a number != 0 or a non-empty string which is not
"0"), execution aborts with a fatal runtime error

[rw@doppelsaurus]/tmp#ed a.pm
a.pm: No such file or directory
a
0;
.
wq
3
[rw@doppelsaurus]/tmp#perl -e 'require a'
a.pm did not return a true value at -e line 1.

The documentation on this states that

The file must return true as the last statement to
indicate successful execution of any initialization code,

However, neither subroutine libraries nor classes usually contain any
initialization code and even in case they do, initialization code
usually doesn't return values. As (somewhat fruitless) protest against
this, I have therefore ended every module I wrote in the last 19/ 20
years with some nonsense comment followed by

1;

(the one above means 'trustee of the eternity')

[Uri Guttman]

>>>>> "T" == T <T...@invalid.invalid> writes:

>> Perl offers the writer of a module to export everything by default
>> (@EXPORT) or to allow the explicit export of functions as needed by the
>> module user (@EXPORT_OK).

T> I can't tell them apart.

very basic. if you use a module and pass in no names to import, it will
default to importing all those names in @EXPORT. you can always
explicitly request which names you want on the use line. @EXPORT_OK
names must be explicitly imported on the use line - they will never be
imported by default.

so you use @EXPORT where there is a set of common symbols to be exported
for most users of the module. @EXPORT_OK is used when you have more
symbols but not needed so often.

check out File::Slurp's code for examples. the commonly used subs
read_file and write_file are exported by default. other subs like
edit_file are in @EXPORT_OK and must be requested on the use line.

use File::Slurp with no args imports read_file and write_file.

use File::Slurp qw( read_file ) imports ONLY read_file

use File::Slurp qw( edit_file ) imports ONLY edit_file

this allows the author of a module to make it easier to default export the
most common stuff and allows the user to import what they only need or
the default list of symbols.

very typical of perl supporting such flexibility.

uri

[T]

Hi $Bill,

Now I get it. And I am writing it down. Thank you!!!

-T

[T]

Hi Uri,

Thank you for helping me with this.

This is what I think you are saying:

@EXPORT is grab bag (everything listed in the array)

@EXPORT_OK is specific. The importer has to specifically
ask for each item in the array

Am I correct?

-T

If I am correct, Modula2 is always @EXPORT_OK, which is
why my confusion. Perl is far more loose, but you can
still tighten it up, if you so choose.

[T]

Hi Sharma,

I think I was having trouble wrapping my mind around "available
on request", which drew a "what that suppose to mean" from me.

Coming from Modula2, it would have far more understandable if
it said "must be specifically imported by name to be used".

To me "available on request" means that the code will be added to
the parent if I make a call to the function from the parent,
which is exactly the behavior I would expect from @EXPORT. So
they both seemed exactly the same to me.

Thank you for helping me with this. I am getting there slowly, but
I am getting there!

-T

[Justin C]

On 2015-07-26, T <T...@invalid.invalid> wrote:
>
> Hi Uri,
>
> Thank you for helping me with this.
>
> This is what I think you are saying:
>
> @EXPORT is grab bag (everything listed in the array)
>
> @EXPORT_OK is specific. The importer has to specifically
> ask for each item in the array

T,

Stop running around like a headless chicken. This stuff is not what a
beginner needs. You're going to confuse youself by learning about the
esoteric practices of Perl experts and still not know how to actually
get anything done. You don't need to know about EXPORT until you're
writing modules - and even then you might not need it, I've written
dozens of modules over the last fifteen or so years and I've never
used it.

Your quest for a Perl education has, so far, covered huge depth, but
no breadth. Ignore the side-streets the replies to your queries may
open, and get the job done. Having a finished project you can look
back on is much more educational than having sheaves of notes but
nothing tangible.

Reading your posts at the moment is like watching a butterfly in a
garden, while it flits hither and there, you are randomly fixating on
subjects irrelevant to either your problem/project, or to a good Perl
education.


Justin.

--
Justin C, by the sea.

[$Bill]

On 7/27/2015 01:27, Justin C wrote:
>
> Reading your posts at the moment is like watching a butterfly in a
> garden, while it flits hither and there, you are randomly fixating on
> subjects irrelevant to either your problem/project, or to a good Perl
> education.

:-D

[Jürgen Exner]

Justin C <justi...@purestblue.com> wrote:

>Stop running around like a headless chicken. This stuff is not what a

>beginner needs.[...]

>
>Your quest for a Perl education has, so far, covered huge depth, but
>no breadth. Ignore the side-streets the replies to your queries may
>open, and get the job done. Having a finished project you can look
>back on is much more educational than having sheaves of notes but
>nothing tangible.
>
>Reading your posts at the moment is like watching a butterfly in a
>garden, while it flits hither and there, you are randomly fixating on
>subjects irrelevant to either your problem/project, or to a good Perl
>education.

Amen to that!!!

jue

[T]

On 07/27/2015 01:27 AM, Justin C wrote:
> On 2015-07-26, T <T...@invalid.invalid> wrote:
>>
>> Hi Uri,
>>
>> Thank you for helping me with this.
>>
>> This is what I think you are saying:
>>
>> @EXPORT is grab bag (everything listed in the array)
>>
>> @EXPORT_OK is specific. The importer has to specifically
>> ask for each item in the array
>
>
> T,

Hi Justin,

> Stop running around like a headless chicken. This stuff is not what a
> beginner needs. You're going to confuse youself by learning about the
> esoteric practices of Perl experts and still not know how to actually
> get anything done.

I prefer Pin Ball. I tried going through Perl courses twice.
I do not learn that way. I actually fell asleep. I learn
by jumping in both feet and doing something useful I need.

> You don't need to know about EXPORT until you're
> writing modules - and even then you might not need it,

I will be doing my first module probably sometime this
week. Or at least that is the game plan.

> I've written
> dozens of modules over the last fifteen or so years and I've never
> used it.

Okay, I will bite. All of the documentation on modules I
have been reading say I have to use EXPORT or EXPORT_OK so
that the internal functions/subs can be seem by the
calling script. How are you doing this without EXPORT?

>
> Your quest for a Perl education has, so far, covered huge depth, but
> no breadth. Ignore the side-streets the replies to your queries may
> open, and get the job done. Having a finished project you can look
> back on is much more educational than having sheaves of notes but
> nothing tangible.

Not the way I work. I open my directory of notes in Krusader
next to my coding window (Leafpad or vi). I also open
several terminal windows (usually xterm) to test snippets.
Then I start coding. If I hit something I do not know, first
I go to my notes, then I hit the web, lastly I ask others.

You will note that this question came from my research off
of two different howto's on the web.

>
> Reading your posts at the moment is like watching a butterfly in a
> garden, while it flits hither and there, you are randomly fixating on
> subjects irrelevant to either your problem/project, or to a good Perl
> education.
>

You know the are irrelevant how? You only know a tiny bit
of my background in programming. You are guessing.

I learn differently than others. What may work for you,
may be dangerous to me (it hurts when I fall asleep and my
head hits the table).

> Justin.
>

Pin Ball, not butterfly. I have a definite goal(s) in mind.
You are just not privy to it, so it seems random to you.

Anyway, I do sincerely appreciate all you and others help.
I will get there!

Many thanks,
-T

I would really like to know how your are getting away without
using EXPORT in your modules.

[shar...@hotmail.com]

On Tuesday, 28 July 2015 04:04:31 UTC+5:30, T wrote:
[snipped]

>
> I would really like to know how your are getting away without
> using EXPORT in your modules.
>

Remember what I wrote in Method-3, nothing exported.
You need to use full names, File::Basename::dirname( ... )

[T]

Hi Sharma,

Is what you are telling me is that in your module you
did not use the EXPORT variable. And you imported
it by explicitly calling the name of the subroutine
inside the module with xxx:yyy:zzz, where zzz
was the name of the subroutine?

In other words, the EXPORT variable is just a labor
saver as far as having the write the whole thing
out.

My initial impression was that the EXPORT variable
had to be used or the outside world could not see
it -- no exceptions. And, that everything else not
stated in the EXPORT variable was hidden.

-T

[Uri Guttman]

>>>>> "T" == T <T...@invalid.invalid> writes:

T> I prefer Pin Ball. I tried going through Perl courses twice.
T> I do not learn that way. I actually fell asleep. I learn
T> by jumping in both feet and doing something useful I need.

>> You don't need to know about EXPORT until you're
>> writing modules - and even then you might not need it,

T> I will be doing my first module probably sometime this
T> week. Or at least that is the game plan.

and even then you will likely not need EXPORT. OO modules (which you
haven't flitted to yet) don't export in general. and if you are writing
basic modules with a few subs, just exporting them all is fine. don't
worry about export_ok until you think there could be a problem with
exporting everything.

>> I've written
>> dozens of modules over the last fifteen or so years and I've never
>> used it.

T> Okay, I will bite. All of the documentation on modules I
T> have been reading say I have to use EXPORT or EXPORT_OK so
T> that the internal functions/subs can be seem by the
T> calling script. How are you doing this without EXPORT?

by not using a different namespace (keep it all in main::) is one
idea. are these modules meant to be reused by others? are they dedicated
to this one script? i have larger programs where i don't use namespaces
but i use modules just to organize the code. this module has this stuff
in it and that has that stuff. works fine without exporting as i don't
use a package anywhere. the modules are dedicated to the script and will
never be shared. modules are for organizing code more than anything
else. they can share subs by export, they can be OO, they can be in the
main:: namespace. your choice as always.

uri

[Mart van de Wege]

T <T...@invalid.invalid> writes:

>
> My initial impression was that the EXPORT variable had to be used or
> the outside world could not see it -- no exceptions. And, that
> everything else not stated in the EXPORT variable was hidden.
>

This is true, but Perl does not have the mechanisms to enforce this
absolutely, unlike other languages. It's a gentlemans' agreement, not a
locked gate.

[T]

On 07/27/2015 10:34 PM, Mart van de Wege wrote:
> T <T...@invalid.invalid> writes:
>
>>
>> My initial impression was that the EXPORT variable had to be used or
>> the outside world could not see it -- no exceptions. And, that
>> everything else not stated in the EXPORT variable was hidden.
>>
> This is true, but Perl does not have the mechanisms to enforce this
> absolutely, unlike other languages. It's a gentlemans' agreement, not a
> locked gate.
>
> Mart
>

That explains it. Thank you!

[T]

Hi Uri,

They will be used universally. But, maybe in the future I
will have ones only for specific modules.

As Mart stated, EXPORT is "suppose" to be used, but is not
enforced. I should use it anyway, for readability. That way
I know what I intent to export.

Thank you for helping me with this!

-T

[shar...@hotmail.com]

On Tuesday, 28 July 2015 09:44:59 UTC+5:30, T wrote:
[snip]

>
> Is what you are telling me is that in your module you
> did not use the EXPORT variable. And you imported
> it by explicitly calling the name of the subroutine
> inside the module with xxx:yyy:zzz, where zzz
> was the name of the subroutine?
>

Please observe that it is not "importing" if you are using
xxx::yyy::zzz form. That's "invoking" the zzz subroutine.

Importing means bringing the subroutine into your namespace,
so that the sub just imported becomes it's part & can hence
be invoked like any of your other subs/vars without needing
a full qualification. e.g., after importing, you could just
say zzz() in your namespace & perl will make sure xxx::yyy::zzz
subroutine gets called. (ofc, assuming there are no namespace collisions)

>
> In other words, the EXPORT variable is just a labor
> saver as far as having the write the whole thing
> out.
>

That's correct. But it's a real convenience, OTW, your
code will be littered with very laborious/unwieldy
symbol names, which will get in the way of it's sanity. e.g.,
compare:
$Personal::Math::Statistical::std_dev
against: $std_dev

Imagine what would you feel if you have to type this long
name in place of $std_dev hundreds of time, not to mention
the choice of module path+names is not in your control. So
the names can be as unpleasant to your liking as possible.

>
> My initial impression was that the EXPORT variable
> had to be used or the outside world could not see
> it -- no exceptions. And, that everything else not
> stated in the EXPORT variable was hidden.
>
> -T

For kids, the belief is that Santa Claus is the bearer of
gifts. It's only later that they realize the reality.
Nevertheless, the kids operate just as well even with their
limited belief set.

[T]

On 07/28/2015 01:39 AM, shar...@hotmail.com wrote:
> $Personal::Math::Statistical::std_dev
> against: $std_dev

Thank you for the help!

Did you make a booboo here? Should that be

$Variance = Personal::Math::Statistical::std_dev
and
$Variance = std_dev

Why did you start the name of a function call with "$"?

Am I missing something?

-T

[Rainer Weikusat]

Mart van de Wege <mvd...@gmail.com> writes:
> T <T...@invalid.invalid> writes:
>
>>
>> My initial impression was that the EXPORT variable had to be used or
>> the outside world could not see it -- no exceptions. And, that
>> everything else not stated in the EXPORT variable was hidden.
>>
> This is true, but Perl does not have the mechanisms to enforce this
> absolutely, unlike other languages. It's a gentlemans' agreement, not a
> locked gate.

It's usually possibly to access names in different namespaces than the
current one by qualifying them (at least true for C++, Lisp and Java).
Perl also supports 'named things' whose names don't exist outside of the
current lexical scope by declaring them via my.

[Rainer Weikusat]

T <T...@invalid.invalid> writes:
> On 07/27/2015 07:30 PM, shar...@hotmail.com wrote:
>> On Tuesday, 28 July 2015 04:04:31 UTC+5:30, T wrote:
>> [snipped]
>>>
>>> I would really like to know how your are getting away without
>>> using EXPORT in your modules.
>>>
>>
>> Remember what I wrote in Method-3, nothing exported.
>> You need to use full names, File::Basename::dirname( ... )
>>
>

> Is what you are telling me is that in your module you
> did not use the EXPORT variable. And you imported
> it by explicitly calling the name of the subroutine
> inside the module with xxx:yyy:zzz, where zzz
> was the name of the subroutine?

When called via qualified name, the subroutine is not 'imported'. This
usually means 'assigning a name in the current package to it'.

[...]

> My initial impression was that the EXPORT variable
> had to be used or the outside world could not see
> it -- no exceptions. And, that everything else not
> stated in the EXPORT variable was hidden.

That's the @EXPORT variable and it doesn't really have any special
meaning: The import method defined by the Exporter module uses it in a
certain way.

Everything which has a name in the symbol table of some package is
universally accessible. In order to do so, the name has to be qualified
with the package name so that the intended symbol table is used to
locate it. Without qualification, the current package is used to resolve
names.

[Mart van de Wege]

Yeah yeah. I was trying to be concise in order not to overload the
reader with information.

Which of course, you in your pedantry, just did, thank you very much.

[Rainer Weikusat]

Mart van de Wege <mvd...@gmail.com> writes:
> Rainer Weikusat <rwei...@mobileactivedefense.com> writes:
>> Mart van de Wege <mvd...@gmail.com> writes:
>>> T <T...@invalid.invalid> writes:
>>>
>>>>
>>>> My initial impression was that the EXPORT variable had to be used or
>>>> the outside world could not see it -- no exceptions. And, that
>>>> everything else not stated in the EXPORT variable was hidden.
>>>>
>>> This is true, but Perl does not have the mechanisms to enforce this
>>> absolutely, unlike other languages. It's a gentlemans' agreement, not a
>>> locked gate.
>>
>> It's usually possibly to access names in different namespaces than the
>> current one by qualifying them (at least true for C++, Lisp and Java).
>> Perl also supports 'named things' whose names don't exist outside of the
>> current lexical scope by declaring them via my.
>>
>
> Yeah yeah. I was trying to be concise in order not to overload the
> reader with information.

The simple example would be 'a namespace is just like a directory in the
filesystem' not 'like a locked strongbox except that in Perl, the locks
never worked' ...

[shar...@hotmail.com]

On Tuesday, 28 July 2015 14:17:03 UTC+5:30, T wrote:
> On 07/28/2015 01:39 AM, shar...@hotmail.com wrote:
> > $Personal::Math::Statistical::std_dev
> > against: $std_dev
>
> Thank you for the help!
>
> Did you make a booboo here? Should that be
>
> $Variance = Personal::Math::Statistical::std_dev
> and
> $Variance = std_dev
>

Mind you, we can import/invoke not only functions/methods but
variables as well. So the $Personal::Math::Stat::std_dev
is a variable(named std_dev) in the module Stat.pm located in
the area {@INC}/Personal/Math/
here whose value we were to use in the current package.

>
> Why did you start the name of a function call with "$"?
>
> Am I missing something?
>
> -T

Actually, if you were to use a function call then it's better written:
Person::Math::Stat::std_dev()

[Justin C]

On 2015-07-27, T <T...@invalid.invalid> wrote:
> On 07/27/2015 01:27 AM, Justin C wrote:
>
>> Stop running around like a headless chicken. This stuff is not what a
>> beginner needs. You're going to confuse youself by learning about the
>> esoteric practices of Perl experts and still not know how to actually
>> get anything done.
>
> I prefer Pin Ball. I tried going through Perl courses twice.
> I do not learn that way. I actually fell asleep. I learn
> by jumping in both feet and doing something useful I need.

I suggest a problem with either the course or the teacher.

>> I've written
>> dozens of modules over the last fifteen or so years and I've never
>> used it.
>
> Okay, I will bite. All of the documentation on modules I
> have been reading say I have to use EXPORT or EXPORT_OK so
> that the internal functions/subs can be seem by the
> calling script. How are you doing this without EXPORT?

No idea, I've never read EXPORT's documentation, it's never been
necessary for my > 50k LOC perl currently in production. But, here's
*a* way of writing a module without it - don't forget, this is Perl,
TMTOWTDI.

/usr/local/lib/site_perl/Local/Consignment/Box.pm
-------------------------------------------------
package Consignment::Box;
use warnings;use strict;

sub new {return bless {}, shift}
sub len {my $self=shift; $self->{l}= shift; return $self->{l}}
sub wid {my $self=shift; $self->{w}= shift@_; return $self->{w}}
sub dep {my $self=shift; $self->{d}= shift; return $self->{d}}
sub vol {my $self=shift; return $self->{d} * $self->{l} * $self->{w}}
1;

(I don't really write modules like this, this is just a proof )


~/tmp/demo.pl
-------------------------
#!/usr/bin/perl
use strict; use warnings; use feature qw/say/;

my $box = Consignment::Box->new;
$box->wid(3); $box->len(4); $box->dep(5);
say $box->vol;

justin@zem:~$ tmp/demo.pl
60

>> Your quest for a Perl education has, so far, covered huge depth, but
>> no breadth. Ignore the side-streets the replies to your queries may
>> open, and get the job done. Having a finished project you can look
>> back on is much more educational than having sheaves of notes but
>> nothing tangible.
>
> Not the way I work.

Then you are destined to spend a long time in the suburbs of Perl
esoterica.

[Rainer Weikusat]

Mart van de Wege <mvd...@gmail.com> writes:
> Rainer Weikusat <rwei...@mobileactivedefense.com> writes:
>> Mart van de Wege <mvd...@gmail.com> writes:
>>> T <T...@invalid.invalid> writes:
>>>
>>>>
>>>> My initial impression was that the EXPORT variable had to be used or
>>>> the outside world could not see it -- no exceptions. And, that
>>>> everything else not stated in the EXPORT variable was hidden.
>>>>
>>> This is true, but Perl does not have the mechanisms to enforce this
>>> absolutely, unlike other languages. It's a gentlemans' agreement, not a
>>> locked gate.
>>
>> It's usually possibly to access names in different namespaces than the
>> current one by qualifying them (at least true for C++, Lisp and Java).
>> Perl also supports 'named things' whose names don't exist outside of the
>> current lexical scope by declaring them via my.
>>
>
> Yeah yeah. I was trying to be concise in order not to overload the
> reader with information.
>
> Which of course, you in your pedantry, just did, thank you very much.

If I write something in the style above (This was halfway a question:
Are there languages enforcing 'namespace encapsulation'?), people
complain about 'pedantry'. When using a more figurative style which is
much more natural to me,

,----

| The simple example would be 'a namespace is just like a directory in the
| filesystem' not 'like a locked strongbox except that in Perl, the locks
| never worked' ...

`----

they often don't understand me at all and frequently end up with the
impression that I'm a (possibly/ probably dangerously deluded)
half-wit.

I could have used the more popular 'blame someone for it' diction:

,----
| You're confusing this with class member encapsulation which is only a
| convention in Perl ("It prefers that you stay out of its living room
| because you weren't invited, not because it has a shotgun"). Namespaces
| aren't even supposed to provide that.
`----

but that's IMHO even less useful in the context of the original question
and even in this semi-skimmed form, needlessly (and counter-productively)
antagonizing (and I've naively imitated that for too long already).

The assumption that everybody must be a naturally-born
Menschversteher-genius, albeit possibly a malevolent one, is a bit far
fetched. This stuff is much more complicated than 'programming
computers', not the least because experiments have the unhealthy
tendency of ending up with someone being beaten senseless ...

[T]

Hi Mart,

I had no trouble following him. He targeted me rather well as
someone with programming experience but no Perl experience.
He did a great job of it.

You also write well too.

-T

[T]

Thank you!

[T]

On 07/28/2015 02:01 AM, Rainer Weikusat wrote:
> T <T...@invalid.invalid> writes:
>> On 07/27/2015 07:30 PM, shar...@hotmail.com wrote:
>>> On Tuesday, 28 July 2015 04:04:31 UTC+5:30, T wrote:
>>> [snipped]
>>>>
>>>> I would really like to know how your are getting away without
>>>> using EXPORT in your modules.
>>>>
>>>
>>> Remember what I wrote in Method-3, nothing exported.
>>> You need to use full names, File::Basename::dirname( ... )
>>>
>>
>> Is what you are telling me is that in your module you
>> did not use the EXPORT variable. And you imported
>> it by explicitly calling the name of the subroutine
>> inside the module with xxx:yyy:zzz, where zzz
>> was the name of the subroutine?
>
> When called via qualified name, the subroutine is not 'imported'. This
> usually means 'assigning a name in the current package to it'.

When I say import, I mean into the resulting assembly code.
I need to learn Perl Speak.

>
> [...]
>
>> My initial impression was that the EXPORT variable
>> had to be used or the outside world could not see
>> it -- no exceptions. And, that everything else not
>> stated in the EXPORT variable was hidden.
>
> That's the @EXPORT variable and it doesn't really have any special
> meaning: The import method defined by the Exporter module uses it in a
> certain way.
>
> Everything which has a name in the symbol table of some package is
> universally accessible. In order to do so, the name has to be qualified
> with the package name so that the intended symbol table is used to
> locate it. Without qualification, the current package is used to resolve
> names.

Would mind you giving me an example?

Thank you for helping me with this.

-T

[T]

On 07/28/2015 02:46 AM, Justin C wrote:
>> I prefer Pin Ball. I tried going through Perl courses twice.
>> >I do not learn that way. I actually fell asleep. I learn
>> >by jumping in both feet and doing something useful I need.

> I suggest a problem with either the course or the teacher.

Hi Justin,

I use to fall asleep in Military Tech School, where I could
get into some serious trouble. My mates use to watch out for
me by kicking me under the table. Not sure whether it was out
of friendship or because they liked kicking me. Maybe a little
of both.

The Tech teachers always knew what had happened when I groaned
in pain. They thought it was pretty funny. Blew their minds that
I aced their courses. 100%. The manuals were written better
than the teaching material. I just read the manuals. Wonderful
schematics. I know, so why don't I read perldoc more.

I remember when they thought they had finally stumped me because
I was taking too long trying to solve a problem. When I
told them that they had jammed the wrong card into the chassis,
it blew their minds. They dismissed the class to take a break.
We peeked at them through a little window. Both teachers were
on the floor yanking on the card. Took them about a half
hour to get it out. Couldn't hear if they were cussing or not.
Pretty funny to all of us even without the sound effects.

So it is hard to separate me from the course and/or the teacher.
I learn differently. I am a bit weird.

-T

I fall asleep in church too. No one to kick me there. Or
at least, no one who is suppose to enjoy it. :-)