[32733] in Perl-Users-Digest
Perl-Users Digest, Issue: 3997 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 22 14:09:30 2013
Date: Mon, 22 Jul 2013 11:09:04 -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 Mon, 22 Jul 2013 Volume: 11 Number: 3997
Today's topics:
Re: [OT] engineering <oneingray@gmail.com>
Re: [OT] engineering <oneingray@gmail.com>
[OT] naming conventions <rweikusat@mssgmbh.com>
Re: Foo::Bar::Libfoobar vs. Libfoobar? <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: Foo::Bar::Libfoobar vs. Libfoobar? <rweikusat@mssgmbh.com>
Re: Foo::Bar::Libfoobar vs. Libfoobar? <oneingray@gmail.com>
Re: the fastest way to create a directory <cwilbur@chromatico.net>
Re: the fastest way to create a directory <news@lawshouse.org>
three computing drawbacks <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Re: three computing drawbacks <uri@stemsystems.com>
Re: using Exporter::export_fail <ben@morrow.me.uk>
Re: using Exporter::export_fail <rweikusat@mssgmbh.com>
Re: using Exporter::export_fail <AndSiPerl@Arcor.De>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 22 Jul 2013 10:36:40 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [OT] engineering
Message-Id: <87d2qaubif.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> The text below is only remotely concerned with software engineering
It's still concerned with food, though, which I'm having a kind
of a lifelong interest in.
[...]
>>> Minus some obvious misconceptions (eg, the 'off the shelf' food is
>>> designed by 'food engineers' to be 'soundly nutrirional', ie,
>>> contain everything fashion currently demands that it should and
>>> not contain anything fashion demands that it currently mustn't,
>> The nutritional requirements of an average healthy adult are more or
>> less well-known (check, e. g., [1]), and do not depend much on
>> "fashion," whatever one's misconceptions may be.
>> [1] http://www.iom.edu/Global/News%20Announcements/~/media/Files/Activity%20Files/Nutrition/DRIs/DRI_Summary_Listing.pdf
> I'm sorry if I didn't pay proper respect to your preferred
> (mis-)conception, but there are simply to many of them, even when
> just counting 'current' ones which include books of
> impressively-looking tables.
While I understand the importance of doubt, I'd like to point
that in this case, these "impressively-looking tables" are based
on the very same kind of scientific evidence as that a surgeon
or a rocket engineer rely upon.
Sadly, the conventional wisdom puts more trust in glossies that
it does in the Institute of Medicine publications.
> Prior to Mad Cow Disease, nutrional requirements of cows were already
> well-known.
Isn't it stretched a bit? It sounds as if prions were once
thought as a constituent of a healthy cow diet, and then, -- all
of a sudden, -- were found not to be. (While in reality, the
"health benefits" of prions are as dependent on "fashion," as
are those of the most of cyanides, dioxins, or strychnine.)
> Do we really have a surge of ideologically blinded suicide bombers
> nowadays?
Somehow, it was my understanding that the family of a suicide
bomber will at times receive support from those "authorizing"
the bombing. Therefore, it indeed may have more to do with the
"diet" than with the "ideology."
[...]
>>> while less sophisticated people like me get by somehow with
>>> vegetables, meat, spices
>> (... Except that all of the above were "engineered," one way or the
>> other.)
> Indeed. I remember an old joke which went roughly like this:
[...]
> With the help of a suitable set of definitions, any term can be
> interpreted to mean anything, at the expense of rendering meaningful
> communication impossible (which may be desired).
Yet another joke I recall says that one doesn't ask questions to
a programmer, for the answer will be true, precise, and useless
in practice.
But the fact is: the varieties grown on the fields of today are
"better" (at least when it comes to the yield; and the
difference may easily be of an order of magnitude) than those
cultivated a century ago; and it's likely that those that will
be grown a century from now will be "better" still.
So, the choice is: to wait, or to use what's available right
now?
>>> and tools to prepare these in some completely 'unscientific' way),
>> The "food engineers" of today have learned that they have to make
>> food "tasty", not "healthy," in order to succeed. Which more or
>> less corresponds to what I may otherwise call an "unscientific" way.
> The purpose of 'the sense of taste' is to enable distinction between
> 'healthy' and 'unhealthy' things one could possibly eat. It works
> better for horses because these tend to approach the matter
> empirically and with an unprejudiced mind, something humans,
> especially humans wielding statistics, rarely do.
The evolution (which gave the horse its "sense of taste" -- as
well as all the other senses) is as wise as it's blind. And, if
it's so easy to fool the eye with an optical illusion, shouldn't
it be at least remotely possible to fool one's sense of taste?
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 have no idea what this was supposed to mean.
>> My point is simple: if the deadline is today, one has to forget
>> about "science" (be it Wirth's, Borlaug's, or someone's else), and
>> use whatever "ingredients" available to solve the task at hand. Be
>> it a program, or a dinner.
> That just a convenient justification the proverbial old poodle uses
> in order to defend against the supposition of having to learn new
> tricks: Whatever the benefits might be, I've got no time for this
> ATM, I'm to busy performing the old ones, constantly working around
> their deficiencies, and won't ever have any time for that, either.
And it's quite natural, and happens in just every field of human
activity. To paraphrase, it takes a touch of genius to do
otherwise.
I'd like to also respond to the other argument here.
> According to my experience, writing 'bad' code (for a suitable
> definition of 'bad') doesn't take less time than writing 'good' code
> (for a suitable definition of 'good')
... 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.
--
FSF associate member #7257
------------------------------
Date: Mon, 22 Jul 2013 10:38:25 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: [OT] engineering
Message-Id: <87bo5uubfi.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> The text below is only remotely concerned with software engineering
It's still concerned with food, though, which I'm having a kind
of a lifelong interest in.
[...]
>>> Minus some obvious misconceptions (eg, the 'off the shelf' food is
>>> designed by 'food engineers' to be 'soundly nutrirional', ie,
>>> contain everything fashion currently demands that it should and
>>> not contain anything fashion demands that it currently mustn't,
>> The nutritional requirements of an average healthy adult are more or
>> less well-known (check, e. g., [1]), and do not depend much on
>> "fashion," whatever one's misconceptions may be.
>> [1] http://www.iom.edu/Global/News%20Announcements/~/media/Files/Activity%20Files/Nutrition/DRIs/DRI_Summary_Listing.pdf
> I'm sorry if I didn't pay proper respect to your preferred
> (mis-)conception, but there are simply to many of them, even when
> just counting 'current' ones which include books of
> impressively-looking tables.
While I understand the importance of doubt, I'd like to point
that in this case, these "impressively-looking tables" are based
on the very same kind of scientific evidence as that a surgeon
or a rocket engineer rely upon.
Sadly, the conventional wisdom puts more trust in glossies that
it does in the Institute of Medicine publications.
> Prior to Mad Cow Disease, nutrional requirements of cows were already
> well-known.
Isn't it stretched a bit? It sounds as if prions were once
thought as a constituent of a healthy cow diet, and then, -- all
of a sudden, -- were found not to be. (While in reality, the
"health benefits" of prions are as dependent on "fashion," as
are those of the most of cyanides, dioxins, or strychnine.)
> Do we really have a surge of ideologically blinded suicide bombers
> nowadays?
Somehow, it was my understanding that the family of a suicide
bomber will at times receive support from those "authorizing"
the bombing. Therefore, it indeed may have more to do with the
"diet" than with the "ideology."
[...]
>>> while less sophisticated people like me get by somehow with
>>> vegetables, meat, spices
>> (... Except that all of the above were "engineered," one way or the
>> other.)
> Indeed. I remember an old joke which went roughly like this:
[...]
> With the help of a suitable set of definitions, any term can be
> interpreted to mean anything, at the expense of rendering meaningful
> communication impossible (which may be desired).
Yet another joke I recall says that one doesn't ask questions to
a programmer, for the answer will be true, precise, and useless
in practice.
But the fact is: the varieties grown on the fields of today are
"better" (at least when it comes to the yield; and the
difference may easily be of an order of magnitude) than those
cultivated a century ago; and it's likely that those that will
be grown a century from now will be "better" still.
So, the choice is: to wait, or to use what's available right
now?
>>> and tools to prepare these in some completely 'unscientific' way),
>> The "food engineers" of today have learned that they have to make
>> food "tasty", not "healthy," in order to succeed. Which more or
>> less corresponds to what I may otherwise call an "unscientific" way.
> The purpose of 'the sense of taste' is to enable distinction between
> 'healthy' and 'unhealthy' things one could possibly eat. It works
> better for horses because these tend to approach the matter
> empirically and with an unprejudiced mind, something humans,
> especially humans wielding statistics, rarely do.
The evolution (which gave the horse its "sense of taste" -- as
well as all the other senses) is as wise as it's blind. And, if
it's so easy to fool the eye with an optical illusion, shouldn't
it be at least remotely possible to fool one's sense of taste?
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 have no idea what this was supposed to mean.
>> My point is simple: if the deadline is today, one has to forget
>> about "science" (be it Wirth's, Borlaug's, or someone's else), and
>> use whatever "ingredients" available to solve the task at hand. Be
>> it a program, or a dinner.
> That just a convenient justification the proverbial old poodle uses
> in order to defend against the supposition of having to learn new
> tricks: Whatever the benefits might be, I've got no time for this
> ATM, I'm to busy performing the old ones, constantly working around
> their deficiencies, and won't ever have any time for that, either.
And it's quite natural, and happens in just every field of human
activity. To paraphrase, it takes a touch of genius to do
otherwise.
I'd like to also respond to the other argument here.
> According to my experience, writing 'bad' code (for a suitable
> definition of 'bad') doesn't take less time than writing 'good' code
> (for a suitable definition of 'good')
... 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.
--
FSF associate member #7257
------------------------------
Date: Mon, 22 Jul 2013 10:35:17 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: [OT] naming conventions
Message-Id: <874nbnym22.fsf@sapphire.mobileactivedefense.com>
--text follows this line--
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> Instead, it is 'called upon' using a sensible name, ie, 'step_in'
> for 'step the in list' or 'step_filter' for 'step the filter
> list'. The names may not be all that sensible but if so, that's
> because of my lacking English, not because of deficiencies of the
> idea itself.
Loosely related anecdote (I feel like telling because this particular
phenomenon should really be documented for its example value): Some
years ago, I used the time between Christmas and New Year's Eve for
investigating a network driver which occasionally caused serious
performance issues customers had been complaining about in an
on-and-off way for one or two years. The code was a pretty typical
example of a 'vendor written "board support" device driver' (judgeing
from the comments, it originally targetted SVR4, had been sort-of
ported to every other operating system under the sun, and was supposed
to support countless generations of wildly incompatible hardware),
that is, a total mess even the people who worked on it didn't
understand anymore. One of the rather harmless 'strange sights' I
found in there was that the RX DMA ring[*] was indexed using a
variable named index while the TX ring used an outdex.
[*] Array treated as ring buffer with the help of index = (index + 1)
% ring_size stepping code used to inform the DMA (direct memory
access) engine on the NIC of the locations of memory buffers set aside
for storing incoming ethernet frames or picking up outgoing ones. The
R in RX stands for reception, the T in TX for transmission. The
acronyms are conventionally used in this way.
------------------------------
Date: Mon, 22 Jul 2013 09:33:36 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: Re: Foo::Bar::Libfoobar vs. Libfoobar?
Message-Id: <ksijmk$gdi$1@news.ntua.gr>
Modules are kept physical as files in directories (simple eh;)
Perl search for modules at root directories of the @INC array. So
Foo::Bar::Libfoobar
means that there is a the following file
$an_INC_root_dir/Foo/Bar/Libfoobar.pm
------------------------------
Date: Mon, 22 Jul 2013 14:18:33 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Foo::Bar::Libfoobar vs. Libfoobar?
Message-Id: <87bo5un36e.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
> I'm curious, what's the current preferred naming scheme for Perl
> bindings to C libraries? Given such modules as GD or
> Image::Magick, I'd assume that the bindings for Libfoobar are
> ought to live in a module named Libfoobar.
>
> Somehow, however, I'd find it tempting to use a longer, yet more
> descriptive, Foo::Bar::Libfoobar; especially if there's a
> related Foo::Bar module already on CPAN, and that Foo::Bar would
> be the "proper" name for Libfoobar, should it be (re)implemented
> as a native Perl library.
>
> Perhaps there's anything else to consider?
First, I would drop the lib-prefix: If it is a standalone Perl module,
'we' already know that it is a library and putting lib in front of the
name is just keeping a convention of so dubious value alive that the
linker has actually contained code to work around it 'for ages'
(intepreting an argument a la -lbarfoo as request to link with a file
named libbarfoo). For the remaining part "it depends": Is 'foobar' an
'unstructured' term in its own right or is 'foo' something which
denotes a class of similar things with bar being a specimen belonging
to it? For the former case, it should be Foobar, integrated in a
suitable 'abstract top-level namespace' ie, Metasyntatic::Foobar, in
the latter case, it should become Foo::Bar.
------------------------------
Date: Mon, 22 Jul 2013 13:49:58 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: Foo::Bar::Libfoobar vs. Libfoobar?
Message-Id: <877ggiu2k9.fsf@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes:
>> I'm curious, what's the current preferred naming scheme for Perl
>> bindings to C libraries? Given such modules as GD or Image::Magick,
>> I'd assume that the bindings for Libfoobar are ought to live in a
>> module named Libfoobar.
>> Somehow, however, I'd find it tempting to use a longer, yet more
>> descriptive, Foo::Bar::Libfoobar; especially if there's a related
>> Foo::Bar module already on CPAN, and that Foo::Bar would be the
>> "proper" name for Libfoobar, should it be (re)implemented as a
>> native Perl library.
>> Perhaps there's anything else to consider?
> First, I would drop the lib-prefix: If it is a standalone Perl
> module, 'we' already know that it is a library
On the contrary, it's a module that provides a Perl interface
for a certain non-Perl library. The library is, however, called
both "the FOOBAR library" and "libfoobar" by the upstream.
Would that be a completely new and stand-alone module, I'd
indeed call it Foo::Bar (or, given that Foo::Bar is already on
CPAN, take some variation on it.)
[...]
> For the remaining part "it depends": Is 'foobar' an 'unstructured'
> term in its own right or is 'foo' something which denotes a class of
> similar things with bar being a specimen belonging to it? For the
> former case, it should be Foobar, integrated in a suitable 'abstract
> top-level namespace' ie, Metasyntatic::Foobar, in the latter case, it
> should become Foo::Bar.
As I've mentioned above, there already is a related Foo::Bar
module on CPAN, which, however, deals with a tiny subset of the
tasks related to Foo Bar. The scope of libfoobar I'm writing
Perl bindings for is considerably wider.
(... Or, rather, it's the Bar::Foo module, as in "FOOBAR," it's
Foo which is a specimen of Bar, not the other way around.)
--
FSF associate member #7257
------------------------------
Date: Sun, 21 Jul 2013 23:19:50 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: the fastest way to create a directory
Message-Id: <878v0zffhl.fsf@new.chromatico.net>
>>>>> "HL" == Henry Law <news@lawshouse.org> writes:
HL> On 18/07/13 20:49, Charlton Wilbur wrote:
>> Thou shalt make thy program's purpose and structure clear to thy
>> fellow man; for thy creativity is better used in solving problems
>> than in creating beautiful new impediments to understanding.
HL> I like it! Is that a Charltonism? Attribution please if not.
I didn't *intentionally* plagiarize! I thought it was well enough known
to not need a citation.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 22 Jul 2013 07:10:40 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: the fastest way to create a directory
Message-Id: <keadnc0Mpqp8UXHMnZ2dnUVZ8uednZ2d@giganews.com>
On 22/07/13 04:19, Charlton Wilbur wrote:
> I didn't*intentionally* plagiarize!
Heavens; have I caused offence? Since I personally didn't recognise the
text, and since you strike me as one of the clueful people in the group,
I thought it was quite possibly original.
It's good anyway; and I liked the rest of the commandments, despite not
being a C programmer to any extent.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 22 Jul 2013 09:26:22 +0300
From: George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com>
Subject: three computing drawbacks
Message-Id: <ksij93$f0k$1@news.ntua.gr>
Not exactly a perl thread. Here are the three drawbacks (I think) that
have kept computing back
1) Binary system. For digital processors should be three or four states
so with the same hardware everything would be four times faster.
2) Bytes should have arbitrary length of “tribits” or “tetrabits
(Unicode is a definition because of the fixed 8bit bytes)
3) Clocks. Everything should be absolute asynchronous so the
chips/electronic would utilized only when needed. Less energy greedy and
faster
------------------------------
Date: Mon, 22 Jul 2013 03:54:42 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: three computing drawbacks
Message-Id: <87zjtfvxkt.fsf@stemsystems.com>
>>>>> "GM" == George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> writes:
GM> Not exactly a perl thread. Here are the three drawbacks (I think)
GM> that have kept computing back
GM> 1) Binary system. For digital processors should be three or four
GM> states so with the same hardware everything would be four times
GM> faster.
been tried. some old russian system had 3 voltage states. much harder to
create in general and likely almost impossible on the scale of todays
chips. having a transistor go all the way on or off is easy. having a
circuit to check the level of voltage accurate is much more
complex. also the logic tables are not easily coded for. what are the
'tri-boolean' function results? also you don't get speedup, you gain
'density' but density is very very cheap now.
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. so unusable that a c
compiler on a dec 20 i used had to put each char in a 36 bit word. bytes
are any size you want on that cpu and sequential access support is built
in. random access is very tricky and slow as code has to do it.
GM> 3) Clocks. Everything should be absolute asynchronous so the
GM> chips/electronic would utilized only when needed. Less energy
GM> greedy and faster
also done already. it is a known thing that async hw will be faster and
use lower power. the problem is with design. sync systems are easier to
design with everything being latched at one time. you can isolate
sections and such. an async chip is much harder to design and it still
needs sync parts to connect to the outside world.
any other 'new' ideas that are actually very old?? :)
thanx,
uri
------------------------------
Date: Mon, 22 Jul 2013 12:49:27 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using Exporter::export_fail
Message-Id: <7rivba-e0c1.ln1@anubis.morrow.me.uk>
Quoth "A. Sicken" <AndSiPerl@Arcor.De>:
> Ben Morrow wrote:
>
> > No. If you must, you can get rid of the method on it's first invocation
> > by deleting the glob from the symbol table, but I wouldn't recommend
> > doing that.
> >
> > You could alternatively write your own import method, which removes
> > enable_debug from the symbol list and calls Exporter->export_to_level to
> > do the actual exporting.
> >
>
> 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. Manipulation of the glob-table is a messy job
> and very error prone; and it does not take modul inheritance into account.
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.
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.
> 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.
> 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.
> 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.
> 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.
Ben
------------------------------
Date: Mon, 22 Jul 2013 14:55:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: using Exporter::export_fail
Message-Id: <877ggin1hm.fsf@sapphire.mobileactivedefense.com>
"A. Sicken" <AndSiPerl@Arcor.De> writes:
> Ben Morrow wrote:
>> No. If you must, you can get rid of the method on it's first invocation
>> by deleting the glob from the symbol table, but I wouldn't recommend
>> doing that.
>>
>> You could alternatively write your own import method, which removes
>> enable_debug from the symbol list and calls Exporter->export_to_level to
>> do the actual exporting.
>
> 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: If
you're creating modules supposed to be used by other people and a
significant minority of these use them in ways you originally
considered to be 'useless', that indicates your 'public interface' is
lacking.
[...]
> 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.
Leaving the issue mentioned above aside, you could create a single
'export fail stub' module, put the subroutine into @EXPORT and then do
a
use export_fail_stub;
to import it as method into every module/ class supposed to utilize
it.
------------------------------
Date: Mon, 22 Jul 2013 19:42:10 +0200
From: "A. Sicken" <AndSiPerl@Arcor.De>
Subject: Re: using Exporter::export_fail
Message-Id: <51ed6ef3$0$6572$9b4e6d93@newsspool3.arcor-online.net>
Rainer Weikusat wrote:
> "A. Sicken" <AndSiPerl@Arcor.De> writes:
>> Ben Morrow wrote:
>>> No. If you must, you can get rid of the method on it's first invocation
>>> by deleting the glob from the symbol table, but I wouldn't recommend
>>> doing that.
>>>
>>> You could alternatively write your own import method, which removes
>>> enable_debug from the symbol list and calls Exporter->export_to_level to
>>> do the actual exporting.
>>
>> 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: If
> you're creating modules supposed to be used by other people and a
> significant minority of these use them in ways you originally
> considered to be 'useless', that indicates your 'public interface' is
> lacking.
>
Many modules are base-class modules to many oher modules - either directly
(as parent) or indirectly (as grand parent).
The potentional down side for the import method is to get unwanted
functionallity... you mostly can ignore that. Beside: Does anyone use the
import-method within a given class modul unless in pragmas to extend perls
bahavior (directly without use-statement)?
The export method - I asume - will be likely more often called. For example
if you want to provide defaults, constants or such thing and that is the
problem - the export-fail method is implicite called if it exists and it
will exists by all module siblings (in case of inheritance). The export_fail
method is usaully used to degrade (more or less gracefull) functionallity
and that as side effect will be pain in the a.. - not only if you need to
find the source of the problem.
> [...]
>
>> 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.
>
> Leaving the issue mentioned above aside, you could create a single
> 'export fail stub' module, put the subroutine into @EXPORT and then do
> a
Ok, the problem for both solutions is messy, because in both cases (either
deleting globs and or build method stubs) means, you have to find a way to
traverse @ISA to find the right parent, caller or what ever make sence.
Some of my modules use Object as their method arguments and decide to work
in different ways upon what comes in...
>
> use export_fail_stub;
>
> to import it as method into every module/ class supposed to utilize
> it.
I do use this kind of stuff very often (as often as I can :-), but as a
stateted above, sometimes this will not work...
So I guess I can close the thread as not so well solved but informative and
I will leave this problem untouched - I know: someday it will hunt me...
Thanks for your help, comments and advices.
Andreas
------------------------------
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 3997
***************************************
