[32734] in Perl-Users-Digest
Perl-Users Digest, Issue: 3998 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 23 21:09:31 2013
Date: Tue, 23 Jul 2013 18:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 23 Jul 2013 Volume: 11 Number: 3998
Today's topics:
Re: [OT] engineering (Seymour J.)
Re: names, values, boxes and microchips (Seymour J.)
Re: names, values, boxes and microchips gamo@telecable.es
Re: names, values, boxes and microchips <ben@morrow.me.uk>
Re: Restart Perl Application upon KDE Restart (Seymour J.)
Re: the fastest way to create a directory <cwilbur@chromatico.net>
Re: the fastest way to create a directory <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: three computing drawbacks (Seymour J.)
Re: three computing drawbacks (Seymour J.)
Re: three computing drawbacks <hjp-usenet3@hjp.at>
Re: three computing drawbacks (Seymour J.)
Re: three computing drawbacks <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: using Exporter::export_fail - SOLVED <AndSiPerl@Arcor.De>
Re: using Exporter::export_fail - SOLVED <ben@morrow.me.uk>
Re: using Exporter::export_fail <AndSiPerl@Arcor.De>
Re: using Exporter::export_fail <rweikusat@mssgmbh.com>
Re: using Exporter::export_fail <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 23 Jul 2013 06:43:56 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: [OT] engineering
Message-Id: <51ee5e6c$2$fuzhry+tra$mr2ice@news.patriot.net>
In <87d2qaubif.fsf@violet.siamics.net>, on 07/22/2013
at 10:36 AM, Ivan Shmakov <oneingray@gmail.com> said:
> But the fact is: the varieties grown on the fields of today are
> "better" (at least when it comes to the yield;
The yield has nothing to do with the nutritional value or the flavor,
and is sometimes at their expense.
> So, the choice is: to wait, or to use what's available right
> now?
That's a false dichotomy, sometimes multiple options are available
right now. The trick is in finding the right options among the
hooplah.
> Why, it was my understanding that it's what at least some of the
> pesticides do: use a toxin which is "tasty" to its victim.
> (Something that, they argue, is the ultimate goal of the
> "fast food" industry of today.)
I find some of the fast food to be remarkably tasteless, although I
must confess a weakness for felaffel stands.
> ... It sounds as if the time required to learn to write "good"
> code was somehow assumed to be zero or negligible, while I
> sincerely doubt that it really is.
Indeed, it is not negligible, and many schools do not take the time to
teach it. I wish that they'd stop teaching the language du jour and
start teaching programming.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 23 Jul 2013 07:14:03 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: names, values, boxes and microchips
Message-Id: <51ee657b$4$fuzhry+tra$mr2ice@news.patriot.net>
In <ksgl9r$tdn$1@speranza.aioe.org>, on 07/21/2013
at 12:47 PM, gamo@telecable.es said:
> __SUB__ A special token that returns a reference to the
>current
> subroutine,
The OP wanted the name; will stringify(__SUB__) work?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 23 Jul 2013 20:43:54 +0000 (UTC)
From: gamo@telecable.es
Subject: Re: names, values, boxes and microchips
Message-Id: <ksmpua$snt$1@speranza.aioe.org>
> __SUB__ A special token that returns a reference to the
>current
> subroutine,
The OP wanted the name; will stringify(__SUB__) work?
------------------
If Rainer wants a name, it is a ugly name, not a name for a pretty debug,
but a name which I thinks is unique, and "could" be used
$ perl -E 'sub a{ say (__SUB__); return 1; }; a();'
CODE(0x8195c00)
------------------------------
Date: Tue, 23 Jul 2013 23:10:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: names, values, boxes and microchips
Message-Id: <bkb3ca-f002.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <ksgl9r$tdn$1@speranza.aioe.org>, on 07/21/2013
> at 12:47 PM, gamo@telecable.es said:
>
> > __SUB__ A special token that returns a reference to the
> >current
> > subroutine,
>
> The OP wanted the name; will stringify(__SUB__) work?
No, though B or Sub::Identify can be used to pull the sub's name out of
the reference.
Ben
------------------------------
Date: Tue, 23 Jul 2013 07:16:47 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <51ee661f$5$fuzhry+tra$mr2ice@news.patriot.net>
In <6vdtba-7721.ln1@anubis.morrow.me.uk>, on 07/21/2013
at 05:13 PM, Ben Morrow <ben@morrow.me.uk> said:
>Well, strictly speaking CTE isn't valid on Usenet,
It may not be valid for 1036, but it is certainly valid for 5536.
Unencoded ISO 8859-1 isn't valid for either.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Mon, 22 Jul 2013 17:31:07 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: the fastest way to create a directory
Message-Id: <87vc42e0ys.fsf@new.chromatico.net>
>>>>> "HL" == Henry Law <news@lawshouse.org> writes:
HL> On 22/07/13 04:19, Charlton Wilbur wrote:
>> I didn't*intentionally* plagiarize!
HL> Heavens; have I caused offence?
Oh, no, but since you didn't recognize it, I realized my assumption that
it was extremely well known was wrong.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 23 Jul 2013 09:33:37 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: the fastest way to create a directory
Message-Id: <ksl84m$nmh$1@news.ntua.gr>
All the posts and answers at this thread are wrong.
The answers was a range from a "Ah, this is trivial and there is a module !"
to simple N approaches
Sometime later I will post the "the fastest way to create a directory".
Actually it have nothing to do (or a little) with directories.
------------------------------
Date: Tue, 23 Jul 2013 08:39:06 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51ee796a$7$fuzhry+tra$mr2ice@news.patriot.net>
In <87zjtfvxkt.fsf@stemsystems.com>, on 07/22/2013
at 03:54 AM, Uri Guttman <uri@stemsystems.com> said:
> GM> 2) Bytes should have arbitrary length of tribits or
>tetrabits
> GM> (Unicode is a definition because of the fixed 8bit bytes)
>already done. see PDP-10/decsystem 10 or 20.
Done earlier on the IBM 7030 and the CDC 3600; neither those not the
DEC version was limited to multiples of 3 or 4. The 7030 in particular
had no problem accessing random bytes, although the byte size was
limited to 1-8 (the others allowed bytes up to a word.)
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 23 Jul 2013 08:32:29 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51ee77dd$6$fuzhry+tra$mr2ice@news.patriot.net>
In <ksij93$f0k$1@news.ntua.gr>, on 07/22/2013
at 09:26 AM, George Mpouras
<nospam.gravitalsun.noadsplease@hotmail.noads.com> said:
>Not exactly a perl thread. Here are the three drawbacks (I think)
>that have kept computing back
The Devil is in the details.
>1) Binary system. For digital processors should be three or four
>states so with the same hardware everything would be four times
>faster.
What gives you that idea? You're talking about a good deal of circuit
complexity, and that affects speed.
>2) Bytes should have arbitrary length of tribits or tetrabits
Why? I can see the utility in arbitrary bytes, but not in bytes
limited to strings of octal or hex digits.
>3) Clocks. Everything should be absolute asynchronous
Again, you are calling for additional complexity without providing
justification. Designers are aware of asynchronous logic and use it
when they believe that the benefits outweigh the costs.
>so the chips/electronic would utilized only when needed.
Mote would be needed.
>Less energy greedy and faster
Perhaps, or perhaps more energy greedy and more expensive.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 23 Jul 2013 18:33:02 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: three computing drawbacks
Message-Id: <slrnkutc1u.vbl.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-23 12:32, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <ksij93$f0k$1@news.ntua.gr>, on 07/22/2013
> at 09:26 AM, George Mpouras
><nospam.gravitalsun.noadsplease@hotmail.noads.com> said:
>>3) Clocks. Everything should be absolute asynchronous
>
> Again, you are calling for additional complexity without providing
> justification. Designers are aware of asynchronous logic and use it
> when they believe that the benefits outweigh the costs.
Here is an article which presents some justification:
http://cacm.acm.org/magazines/2012/10/155552-the-tyranny-of-the-clock/fulltext
It also mentions a few reasons why clock-less logic is rarely used.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 23 Jul 2013 17:43:25 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: three computing drawbacks
Message-Id: <51eef8fd$6$fuzhry+tra$mr2ice@news.patriot.net>
In <slrnkutc1u.vbl.hjp-usenet3@hrunkner.hjp.at>, on 07/23/2013
at 06:33 PM, "Peter J. Holzer" <hjp-usenet3@hjp.at> said:
>http://cacm.acm.org/magazines/2012/10/155552-the-tyranny-of-the-clock/fulltext
The author is a blast from the past; I'm not sure whether kids these
days will recognize the name. It looks like E&S still exists.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 24 Jul 2013 02:06:26 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: three computing drawbacks
Message-Id: <ksn2a9$2umn$1@news.ntua.gr>
I remember solving differential equations with capacitors and coils at the
lab.
Soem guys displayed fractals at the oscillograph !
------------------------------
Date: Mon, 22 Jul 2013 23:33:41 +0200
From: "A. Sicken" <AndSiPerl@Arcor.De>
Subject: Re: using Exporter::export_fail - SOLVED
Message-Id: <51eda537$0$9515$9b4e6d93@newsspool1.arcor-online.net>
Rainer Weikusat wrote:
> This is not quite true: According to the documentation,
> Exporter::import will end up calling the export_fail method when an
> import of a symbol listed in @EXPORT_FAIL is attempted. Modules/
> classes not using that would be unaffected. For others, the default
> behaviour of turning every attempt to import something on @EXPORT_FAIL
> into a compile-time error would change. A workaround for that could be
> to add
>
> return &Exporter::export_fail unless $_[0] eq __PACKAGE__;
>
With this you made my day: Thanks. So Exporter does, what I want to avoid
for my self - it traverse the calling tree to find its right member
export_fail.
The part where @EXPORT_FAIL must exist, does not actually help, because i
will implement it to all my modules as trigger/hook to enable debugging code
- but as the return line above show: Only if the given classename (by
caller) is not equal to the static class name, which implements export_fail
you have to call Exporter::export_fail staticly to defere the handling
stuff. So no inheritance - and that is exactly what I wanted. I tested it so
far and you are totally right.
Out of curiousity: My docs (perldoc 5.16.3) do not cite this... gush...
Many many thanks for your help: Problem solved!
Andreas
> as first line to your export_fail method. This would forward the call
> to the default implementation unless the method was called 'directly'
> via the module/ class defining it.
------------------------------
Date: Tue, 23 Jul 2013 00:14:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using Exporter::export_fail - SOLVED
Message-Id: <d0r0ca-vug1.ln1@anubis.morrow.me.uk>
Quoth "A. Sicken" <AndSiPerl@Arcor.De>:
> Rainer Weikusat wrote:
>
> > This is not quite true: According to the documentation,
> > Exporter::import will end up calling the export_fail method when an
> > import of a symbol listed in @EXPORT_FAIL is attempted. Modules/
> > classes not using that would be unaffected. For others, the default
> > behaviour of turning every attempt to import something on @EXPORT_FAIL
> > into a compile-time error would change. A workaround for that could be
> > to add
> >
> > return &Exporter::export_fail unless $_[0] eq __PACKAGE__;
> >
> With this you made my day: Thanks. So Exporter does, what I want to avoid
> for my self - it traverse the calling tree to find its right member
> export_fail.
The call to export_fail is in Exporter::Heavy::heavy_export (which is
the implementation of Exporter's export method) and looks like this:
@failed = $pkg->export_fail(@failed);
where $pkg is the class the export method was called on. This is a
method call, so it uses inheritance. I'm not sure what you mean by 'the
calling tree'; do you mean the inheritance tree of the class 'export'
was called on?
> The part where @EXPORT_FAIL must exist, does not actually help, because i
> will implement it to all my modules as trigger/hook to enable debugging code
Um, why? If a class shouldn't support enable_debug, why would you put it
in @EXPORT_FAIL?
> Out of curiousity: My docs (perldoc 5.16.3) do not cite this... gush...
Do not cite what?
Ben
------------------------------
Date: Mon, 22 Jul 2013 20:19:18 +0200
From: "A. Sicken" <AndSiPerl@Arcor.De>
Subject: Re: using Exporter::export_fail
Message-Id: <51ed77a8$0$6581$9b4e6d93@newsspool3.arcor-online.net>
Ben Morrow wrote:
> I agree it's a bad idea.
>
>> The other way around (for inheritance only) I guess would be to write
>> export_fail-stubs for every single modul (currently about 20) which is
>> also a messy job :-( - and it would make it worse - because then every
>> modul would need to have an export_fail method which is completely
>> unneccessary for the object stuff.
>
> This package you are exporting from is a base class? Certainly, that
> would be messy.
Most of them, you guessed right.
>
> Incidentally, are you inheriting from Exporter or importing its import
> method? If you are inheriting then you've just scquired a whole lot of
> methods anyway.
No, no - I use ONLY the import method in my own classes this way:
use Exorter qw/import/;
>
>> Somehow I was hoping to scope the usage to a BEGIN{} block, so it will
>> invoked only once and then goes out of scope. The real annoying thing is
>> that the objects itself have debugging capability for their state and
>> contents whereas the debugging I reffered to is to trace the methods in a
>> certain module itself and I need this functionallity because of the very
>> nature of frameworks and their deep nested calling stack.
>
> A further alternative would be not to use a 'use' parameter at all but
> simply to provide a function or method to turn this debugging on. Given
> that it has global effect, I doubt you'll want to do this very often.
That is the point: I can not decide at this point, where and when classes
will be used - so having a global sitting around will work perfectly except
for cases where you deal with stuff like web-frontend, pg-backend and so
on... my modules will work as type of connectors or templates.
>
>> To use the export_to_level method isn't an option so far to me because I
>> do not know where to export; a caller based reference doesn't work all
>> the time, so I have to inspect @ISA to find the modul where to export to.
>
> I don't understand what you mean here. If you're currently using
> Exporter::import then writing your own import method which calls
> Exporter->export_to_level(1, @exports) will do the same thing.
Sorry my fault. Most modules work like connectors and they are somehow aware
what to do. For example: I have written two modules - one
(Ext::Data::Object::Float) does stuff like defining what a float number
should look alike (size, precision, minimum and many things more) - the
other (PgSerializer) stuff things into an Postgres-Table and or Database.
Now if you define a Float-object and provide it to PGSerializer it will use
the given definitions to create a fitting table - even SQL-constraints. Same
goes for a String object. But if you provide an PgSerializer object to a
Float object (Ex. Ext::Data::Object::Float->new($PgSerializer) ) it will
simply create a Float object with meating definitions.
For both objects exists a dumper class: If you call that with Float it will
behave in default menor (writing some xml) but if you put the Float object
wrapped in PgSerializer in it, it will pass handling the stuff to
PgSerializer.
In short you can call them nested and depending on how they are nested you
get functionality.
This works because of a well defined object and method api that carry
required information. One leg to it is to reuse code (where inheritance come
in).
>
>> It seems a long way to go und feels frustrating.
>
> Is any of this important? Does it actually matter that your objects have
> an extra method? After all, they have a useless 'import' method already.
To Rainer I have explained before why the import method do not bother me
(much) and why the export and the allways implicite called export_failed
method is in such a case different.
>
>> Do you have any knowlege about fitting cpan modules or maybe
>> references/links where I can search for.
>
> There are other Exporters on CPAN; possible one will do what you want.
>
>> EDIT: Maybe I am thinking in the wrong direction! When is the export_fail
>> method called? Before or after any BEGIN-block? Or is there any run-state
>> that can be called right after export_fail (as hook for example)?
>
> export_fail is called from Exporter::export, which is called from
> Exporter::import or Exporter::export_to_level.
I need a run-state like exporter is called right after its own begin-blocks
but before your modul begin-blocks. In that case I can simply use a begin-
block to override or delete my own eport_fail method and resolve any
depending problem at once...
So far I haven't found information about when export is called.
>
> Ben
Also to you many thanks for your help.
Andreas
------------------------------
Date: Mon, 22 Jul 2013 19:47:24 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: using Exporter::export_fail
Message-Id: <87mwpel9dv.fsf@sapphire.mobileactivedefense.com>
"A. Sicken" <AndSiPerl@Arcor.De> writes:
> Rainer Weikusat wrote:
>> "A. Sicken" <AndSiPerl@Arcor.De> writes:
[...]
>>> Ok. The method I want to get rid of is the export_fail-method (not the
>>> local tied enable_debug var or the symbol) because you can call it on
>>> every object created through this modul.
>>
>> And what's the problem with that? 'class modules' I'm using usually
>> also contain auxiliary subroutines which could also be called 'on
>> every object' except that this wouldn't be particularly useful
[...]
> Many modules are base-class modules to many oher modules - either directly
> (as parent) or indirectly (as grand parent).
[...]
> the export-fail method is implicite called if it exists and it
> will exists by all module siblings (in case of inheritance).
This is not quite true: According to the documentation,
Exporter::import will end up calling the export_fail method when an
import of a symbol listed in @EXPORT_FAIL is attempted. Modules/
classes not using that would be unaffected. For others, the default
behaviour of turning every attempt to import something on @EXPORT_FAIL
into a compile-time error would change. A workaround for that could be
to add
return &Exporter::export_fail unless $_[0] eq __PACKAGE__;
as first line to your export_fail method. This would forward the call
to the default implementation unless the method was called 'directly'
via the module/ class defining it.
------------------------------
Date: Mon, 22 Jul 2013 22:41:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using Exporter::export_fail
Message-Id: <vhl0ca-euf1.ln1@anubis.morrow.me.uk>
Quoth "A. Sicken" <AndSiPerl@Arcor.De>:
> Ben Morrow wrote:
>
> > I don't understand what you mean here. If you're currently using
> > Exporter::import then writing your own import method which calls
> > Exporter->export_to_level(1, @exports) will do the same thing.
> Sorry my fault. Most modules work like connectors and they are somehow aware
> what to do. For example: I have written two modules - one
> (Ext::Data::Object::Float) does stuff like defining what a float number
> should look alike (size, precision, minimum and many things more) - the
> other (PgSerializer) stuff things into an Postgres-Table and or Database.
> Now if you define a Float-object and provide it to PGSerializer it will use
> the given definitions to create a fitting table - even SQL-constraints. Same
> goes for a String object. But if you provide an PgSerializer object to a
> Float object (Ex. Ext::Data::Object::Float->new($PgSerializer) ) it will
> simply create a Float object with meating definitions.
> For both objects exists a dumper class: If you call that with Float it will
> behave in default menor (writing some xml) but if you put the Float object
> wrapped in PgSerializer in it, it will pass handling the stuff to
> PgSerializer.
> In short you can call them nested and depending on how they are nested you
> get functionality.
> This works because of a well defined object and method api that carry
> required information. One leg to it is to reuse code (where inheritance come
> in).
I don't see what any of that has to do with exporting. If you replace
use Exporter "import";
with
require Exporter;
sub import {
my ($from, @args) = @_;
my $to = caller;
my @syms = grep $_ ne "enable_debug", @args;
if (@syms != @args) {
# enable global debugging
}
$from->Exporter::export($to, @syms);
}
I believe it will do exactly what you want. Of course, any subclasses
which inherit this import method will also support the 'enable_debug'
option; if that's a problem then either don't make the base class the
one that supports the option, or, as Rainer says, check $from to make
sure this is 'your' import method.
(Rereading the docs and source of Exporter, export_to_level only works
if you inherit from Exporter. ->export works without inheritance, as
long as you call it like that.)
> > export_fail is called from Exporter::export, which is called from
> > Exporter::import or Exporter::export_to_level.
> I need a run-state like exporter is called right after its own begin-blocks
> but before your modul begin-blocks. In that case I can simply use a begin-
> block to override or delete my own eport_fail method and resolve any
> depending problem at once...
Sorry, what? The whole of your module file (including any BEGIN blocks)
is compiled and run before perl even attempts to call the import
method...
> So far I haven't found information about when export is called.
I just told you. Exporter::import and Exporter::export_to_level both
call Exporter::export to do the actual exporting.
[Well, there's some gnarly special-casing of simple cases, but that
doesn't apply here. And export_to_level actually calls the exported-from
package's ->export method, and expects it to inherit from Exporter.]
Or do you mean when import is called?
use Foo @args;
is exactly equivalent to
BEGIN {
require Foo;
Foo->import(@args);
}
Ben
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3998
***************************************
