Name for an A/B testing module?
Hi all, I've written an A/B testing module for Perl, but I suspect the name Test::AB will annoy people since people expect modules in the Test:: namespace to be about traditional testing tools (exporting test functions or providing a test framework in which said functions are used). This module simply allows you specify the number of visitors and the number of *converted* visitors per experiment and for each experiment, returns a z-score and percentage to help you understand if you should reject the null hypothesis. Needless to say, this doesn't fit into the Boolean yes/no proposition of standard testing in Perl, so namespace suggestions are welcome. Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/
Re: Name for an A/B testing module?
From: Leon Timmermans faw...@gmail.com Sounds like good work. Now I just wish I'd trust people to interpret statistics in a useful manner :-/ Yes, that's a certainly an issue and I don't know exactly how to deal with it. In particular, there's a little known, but hard problem, in A/B testing: http://www.einarsen.no/is-your-ab-testing-effort-just-chasing-statistical-ghosts/ Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/
Re: Name for an A/B testing module?
Ooh, we could collaborate! My work is deliberately limited and if you're taking a different approach, that might help. Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/ - Original Message - From: Adrian Howard adri...@quietstars.com To: Ovid publiustemp-moduleautho...@yahoo.com Cc: module-authors@perl.org module-authors@perl.org Sent: Sunday, 29 September 2013, 12:31 Subject: Re: Name for an A/B testing module? Well done - this will likely mean I can bin my one in development ;-) Statistics::AB? Adrian On 29 September 2013 09:44, Ovid publiustemp-moduleautho...@yahoo.com wrote: Hi all, I've written an A/B testing module for Perl, but I suspect the name Test::AB will annoy people since people expect modules in the Test:: namespace to be about traditional testing tools (exporting test functions or providing a test framework in which said functions are used). This module simply allows you specify the number of visitors and the number of *converted* visitors per experiment and for each experiment, returns a z-score and percentage to help you understand if you should reject the null hypothesis. Needless to say, this doesn't fit into the Boolean yes/no proposition of standard testing in Perl, so namespace suggestions are welcome. Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/
Re: Name for pragma type module?
Since you're asking about related modules, I have an Attribute::Context module
on the CPAN. I released it years ago, no one used it, so now test failures are
piling up with newer releases:
http://search.cpan.org/dist/Attribute-Context/lib/Attribute/Context.pm
Maybe that will help?
Cheers,
Ovid
--
IT consulting, training, international recruiting
http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Live and work overseas - http://www.overseas-exile.com/
From: Jim Schueler j...@tqis.com
To: module-authors@perl.org
Cc: j...@tqis.com
Sent: Tuesday, 23 July 2013, 16:37
Subject: Name for pragma type module?
Hello.
I would like to publish the modules described below. In particular, I'm
requesting recommendations for a good name.
Frequently I write simple mutators as functions. The mutator should return
a scalar when a scalar is passed and a list when a list is passed. I was
looking for an existing solution, and concluding there was none, wrote my
own. This module defines two function attributes as shown below:
## Example uses lc to represent an arbitrarily complex mutator
sub lowercase : ScalarContext('first') {
return map { lc } @_ ;
}
print scalar lowercase('Jim'), \n ; ## prints 'jim' instead of 1
There several variants:
sub lowercase : ScalarContext('last') {...} ## returns the last element
sub lowercase : ScalarContext('count') {...} ## default behavior
sub lowercase : Listify {...} ## aristotle's response
The Listify attribute was added after someone recommended pasting a listify()
function in every project instead of this module. Maybe this is common
practice; and if so, wouldn't a CPAN module be preferable?
One option is to release this module as a pragma. Note the difference in
invocation:
## Function::ReturnScalar name used in blog example
use Function::ReturnScalar ; ## pragma
use base Function::ReturnScalar ; ## standard
I've posted this discussion on perlmonks and perl blogs:
http://blogs.perl.org/users/jim_schueler/2013/07/function-return-in-scalar-context.html
My question is basically:
1. Is there an existing module? (Apparently not)
2. Is this module useful to anyone else?
3. Code review of proposed solution
I was hoping for more encouraging responses, which I've summarized as follows:
1. Non-specific attacks unrelated to the question about usefulness.
2. Generally used work-arounds are better (without explanation).
3. A couple indications that the module would be useful.
Maybe these responses help test the moxie of a new wannabe contributor?
Although the general response tone was discouraging, no one gave any specific
reasons against release. And, at least, publishing this module will help
*my* code base.
I'd like to release this module following all the best practices. Can anyone
help?
Thanks!
-Jim
Re: Name for pragma type module?
From: Aldo Calpini d...@perl.it regarding the other option, eg. the attribute way, there seems to be a module already on CPAN for this: http://search.cpan.org/~ovid/Attribute-Context-0.042/lib/Attribute/Context.pm I might add that I let that module languish, so if anyone is interested in taking it over, that's great. It needs some updating to get it to pass with recent versions of Perl. Cheers, Ovid -- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/
Re: Please advise before I submit to CPAN
- Original Message
From: Aristotle Pagaltzis pagalt...@gmx.de
I would write that
my $self = shift;
my ( $name ) = @_;
:-)
(To my way of thinking, the invocant is not a positional
argument, so I always pull it out of @_ with a `shift`,
whereas I unpack arguments using list assignment.)
Why does this matter? Aside from being able to do this a touch cleaner:
sub foo {
my $self = shift;
my ($name) = @_;
$self-SUPER::foo($name); # if you're still using SUPER::
...
}
I know this formatting is common, but what practical benefit does it gain? It
almost sounds like how I do this:
my $val = join '-' = @args;
The '=' is something I'm often asked about because I like to visual
distinction
between subject and predicate. Aside from that, I'm unsure what value this
provides other than conforming to a particular coding preference (and it's more
ops, but that's probably not enough for it to be a performance win to avoid it).
(I'm not criticising. I'm genuinely curious to know how this helps)
Cheers,
Ovid --
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: The CPAN Definitive Tags Spec
- Original Message From: Shlomi Fish shlo...@iglu.org.il I can't tell you how many times I've supplied a complete patch, with tests and documentation, for a known bug in a module and had absolutely no response from the author. If I am willing to do all of that work for them and they ignore it, why on earth would they bother with a new release just to fix a tag which doesn't alter the module's functionality? They won't. They're not going to care. And I'd like to add that you're guilty of the same sin: https://rt.cpan.org/Public/Bug/Display.html?id=54214 Touché. On the plus side, I think our failure to apply the patch bolsters my argument ;) Cheers, Ovid (hanging his head in shame) -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: The CPAN Definitive Tags Spec
- Original Message From: Shlomi Fish shlo...@iglu.org.il On Saturday 07 August 2010 00:44:05 Ovid wrote: Laughing at that active_dev tag. What's wrong with it? First, my apologies for being so flippant. That was rude of me and I'm sorry. I just typed what popped into my head without thinking about how it sounded. Let's just say, for the sake of argument, that these tags become popular. Over time, the majority of CPAN modules are not actively developed because the authors move on to other languages, other careers, or just forget about the darned module. They're going to leave the active_dev tag there because they forgot about it, not because it's true. I can't tell you how many times I've supplied a complete patch, with tests and documentation, for a known bug in a module and had absolutely no response from the author. If I am willing to do all of that work for them and they ignore it, why on earth would they bother with a new release just to fix a tag which doesn't alter the module's functionality? They won't. They're not going to care. Thus, I confidently predict that the CPAN would become littered with tons of active_dev tags which are flat out lies and thus undermine our confidence in tags in the first place. On a related note, I've not made a new release of Sub::Override in 5 years because it's complete and apparently correct. Is it actively developed or not? I can't say I've really been paying attention here, but while some tags (requires C compiler) seem like they might be reasonable, other tags such as black_magic seem highly subjective. And the source_filter tag seems to belong in the black_magic category. Well, tags may be overlapping. But not all black_magic modules are source filters (e.g: Error.pm which is not a source filter, but is black magic.). That misses the point. Who defines black_magic? What I see as normal code (e.g., reaching into a typeglob) is seen as black magic to others. I'm not saying this module is a bad idea, but ambiguous/subjective tags don't seem useful to me. adopt_me doesn't seem problematic. However, maybe I'll use this module and create a works_on_my_machine tag :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: The CPAN Definitive Tags Spec
Laughing at that active_dev tag. I can't say I've really been paying attention here, but while some tags (requires C compiler) seem like they might be reasonable, other tags such as black_magic seem highly subjective. And the source_filter tag seems to belong in the black_magic category. How were these tags chosen? Heck, where did the entire idea originate? I've not been paying attention lately (getting married will do that to you). This seems a bit odd, though I somewhat like the thought (particularly the adopt_me tag). Cheers, Ovid-- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 - Original Message From: Shlomi Fish shlo...@iglu.org.il To: module-authors module-authors@perl.org Cc: rethinking-cpan rethinking-c...@googlegroups.com Sent: Fri, 6 August, 2010 18:58:02 Subject: The CPAN Definitive Tags Spec Hi all! Today I converted the Definitive Tags list to a POD-based spec. One can find it inside a Mercurial repository here: http://bitbucket.org/shlomif/rethinking-cpan/src/tip/CPAN-Definitive- Tags/cpan-definitive-tags.pod (Short URL: http://xrl.us/bhvcyb ). Any comments would be welcome. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ What does Zionism mean? - http://shlom.in/def-zionism God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Roles on the CPAN
I'm thinking about writing a module which is merely a role (Moose::Role) which one must consume. While there doesn't appear to be a standard for this, I was thinking about trying to set a precedent and use the Does:: namespace. For example, if you want a upload a role which serializes things to YAML, you might call it Does::Serialize::YAML to make it clear it's a role to be consumed and not a stand-alone package. Thoughts? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Perl 6 and the CPAN?
Hi all, I've started writing Config::INI, an INI reader/writer in Perl 6. It's on github at http://github.com/Ovid/Config-INI. This has raised several interesting issues, but the most important is that I didn't check the CPAN, but it turns out Ricardo Signes has a Perl 5 version: http://search.cpan.org/dist/Config-INI/. Can we have identically named P5 and P6 modules on the CPAN? We should be able to, but I don't that will actually fly. I know there was a fair chunk of discussion regarding Perl 6 on the CPAN, but have we gotten anywhere? More and more Perl 6 code is being written and sooner or later, people would like someplace to put it other than github or code.google.com :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Perl 6 and the CPAN?
--- On Sat, 2/1/10, David Golden xda...@gmail.com wrote: From: David Golden xda...@gmail.com I suggest taking this up on the cpan-workers list instead of module-authors. David Done, and thank you. Side note: I usually don't post replies with just a thanks as that seems to clog up mailing lists with useless chatter, but I hate to seem ungrateful and justa private email to the author still potentially looks ungrateful to others. Sigh. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: module name for test data?
- Original Message From: David Nicol davidni...@gmail.com you could put the word corpus in there somewhere, since you're publishing some test data. For others to use it, who might be looking for test data, that's what a corpus is in test data jargon (i believe.) Test::Corpus::audio::mpd would set an example of publishing test data to CPAN under the Test::Corpus prefix. ++! You know, I never did like this idea of publishing test data to the CPAN, but I ever dislike even more the idea of people stretching it for legitimate uses. The Test::Corpus:: namespace is lovely. If you publish there and folks are reasonably happy with this, let us know and I'll post some stuff to my blog and Perl-QA to get others to know about this namespace (and potentially use it). If these corpuses (corpi?) can also guarantee a stable interface, we may even be able to guarantee common sets of test data which different *developers* can use, not just modules. To that end, how would we guarantee a stable interface which people could trust, or be able to quickly bail out or skip if there's an incompatible change? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: module name for test data?
--- On Wed, 30/9/09, Ovid publiustemp-moduleautho...@yahoo.com wrote: From: Ovid publiustemp-moduleautho...@yahoo.com You know, I never did like this idea of publishing test data to the CPAN, but I ever dislike even more the idea of people stretching it for legitimate uses.. What a load of crap. Let me try that again :) You know, I never did like this idea of publishing test data to the CPAN, but I dislike even more the idea of telling people they can't stretch the CPAN for legitimate uses. jeers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Which Parser Generator to Use?
--- On Sun, 6/9/09, Shlomi Fish shlo...@iglu.org.il wrote: From: Shlomi Fish shlo...@iglu.org.il 2. Parse::RecDescent - very impressive feature set, but a little slow, and has been under-maintained (though it seemed to have improved slightly with several new releases in 2009). It also tends to be hard to debug its errors. Hi Shlomi, I didn't see it mentioned yet, but you might want to check out Damian Conway's new http://search.cpan.org/dist/Regexp-Grammars/ It requires 5.10, but it's much faster than Parse::RecDescent and has a clean syntax very close to Perl 6 rules. It's well documented and hooks directly into the Perl regex engine, hence its speed. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: I'd like a way to abandon a module
Why not create an ABANDONED pause ID? Then you could just assign ownership to that. Er, or they'd have to make a release, wouldn't they? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 - Original Message From: Andy Lester a...@petdance.com To: Adrian Howard adri...@quietstars.com Cc: Jonathan Leto jal...@gmail.com; module-authors@perl.org Sent: Thursday, 13 August, 2009 13:38:41 Subject: Re: I'd like a way to abandon a module On Aug 13, 2009, at 6:43 AM, Adrian Howard wrote: Make an ABANDONED PAUSE user and give modules to it? I thought of that, but unless somehow the modules came out of PETDANCE into ABANDONED's directory, I still look like the owner. -- Andy Lester = a...@petdance.com = www.theworkinggeek.com = AIM:petdance
Re: DateTime::Duration::W3C?
- Original Message From: Paul Hoffman nkui...@nkuitse.com You can download ISO 8601 (3rd ed.) at this URL: http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetchnodeid=4021199 Thanks Paul! Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
DateTime::Duration::W3C?
If this is on the CPAN, please let me know. I can't find it. If not, we probably need it at work. The W3C duration standard (http://www.w3.org/TR/xmlschema-2/#duration), derived from the ISO 8601 duration standard, allows one to specify durations in a format like PnYnMnDTnHnMnS (e.g.: P1Y2MT2H, a duration of one year, two months and two hours). I can't find a proper parser for it and it turns out to have some tricky bits. Basically, I want to do this: my $duration = DateTime::Duration::W3C-new(P1Y2MT2H); Which would be more or less equivalent to: my $duration = DateTime::Duration-new( years = 1, months = 2, hours = 2, ); I can write this and try to handle the special cases I find documented (I'll be damned if I'm going to pay 130 Swiss Francs for the damned ISO 8601 standard), but I'd love to know if it's already out there. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: lexical warnings question
- Original Message
From: Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net
On Tue, Jun 16, 2009 at 02:39:21PM -0700, Bill Ward wrote:
So, do I need to monkey with $SIG{__DIE__} or something?
$SIG{__WARN__} = sub { die @_ };
Apply more advanced filtering to @_ as desired.
Just a quick ack through most of my CPAN modules shows that messing with
__WARN__ is very hit-and-miss.
ack __WARN__ /opt/local/lib/perl5/site_perl/5.8.8/
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Module::Build + documenation woes
- Original Message From: Jonathan Yu jonathan.i...@gmail.com I have *never* used h2xs to start a module, though I have copied the basic scripts/structure/etc that other packages have (which likely began with h2xs at one point or another)... I use Module::Starter myself, though I keep meaning to play with Dist::Zilla. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Module::Build + documenation woes
- Original Message
From: Ken Williams kena...@gmail.com
On Tue, May 12, 2009 at 9:06 AM, Eric Wilhelmwrote:
Isn't that what Ken did some time ago? Ah... 0.31 added
the create_license = 1 option, but I guess it didn't get documented.
Oopsie. Yeah.
create_license = 1,
create_readme = 1,
and Bob's your uncle.
I only learned about the 'create_readme' option a few days ago when I was
browsing the CPAN.
I can't speak for most others, but even though I've done some pretty serious
things with Module::Build (and I absolutely love it), I'm guessing that my
common usage ( 95% of the modules I write) matches everyone else's common
usage: writing a simple Build.PL
What would be nice if if the main documentation
(http://search.cpan.org/dist/Module-Build/lib/Module/Build.pm) had, right at
the top, sample Build.PL code in the synopsis. After that, maybe a few
optional configurations or recommended Build.PL files. For example, here's
a sample Build.PL that I'm using and the various features are ones that I
learned from mailing lists because I get lost in the docs :)
use Module::Build;
my $builder = Module::Build-new(
module_name= 'AI::Logic',
license= 'perl',
dist_author= 'Curtis Ovid Poe o...@cpan.org',
dist_version_from = 'lib/AI/Logic.pm',
build_requires = { 'Test::Most' = 0.21, },
requires = { 'Scalar::Util' = 1.19, },
add_to_cleanup = ['AI-Logic-*'],
create_readme = 1,
create_makefile_pl = 'traditional',
);
$builder-create_build_script();
I suspect, but can't prove, that many potential Module::Build users have the
same issues. They just want to know how to write a useful Build.PL. Maybe
after that a quick example of how to extend it to, say, set up a test database
or some other build action. Then and only then go into the mind-numbing detail
about every single bell and whistle that Module::Build provides :)
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: a lot of silliness about Module::Build
- Original Message From: Andy Lester a...@petdance.com Don't know. Just saying why I have never switched: Because I've never heard a compelling enough reason to make the time investment. Exactly! Thank you, Andy++ Me? I use M::B for most of my modules. Generally don't need to, but I provide a Makefile.PL for those who don't like MB. However, if I have complicated build needs, EU::MM is very, very hard to work with. I have no idea why people debate this. MB and MI are clearly superior to EU::MM [1], but so what? Don't need 'em? Don't use 'em. I'm sorry. What were people saying again? Cheers, Ovid 1. This is according to the *maintainers* of EU::MM. Lots of people who've never written a Makefile which must run on an unknown operating system with an unknown version of make have different opinions, though. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Module for detecting if a method is overridden
- Original Message
From: Eric Wilhelm enoba...@gmail.com
Or:
define(bar = sub {...});
Yeah, that forces syntax to be rather widespread.
I always seem to want to be able to install something like a UNITCHECK
block into caller from import(). Alas.
And anyway, the attributes implementation can probably be made to do
wrapping for run-time checking and various other features.
How does Perl 6 (or some other language) do (or allow for) this?
Regrettably, no matter how much I play with the syntax, I can't get something
that's really convenient short of attributes and those aren't terribly popular
(and they're problematic since they aren't Perl code). Schwern's
Method::Signatures might work as users have already drunk the Kool-Aid, but
since Perl 5 doesn't offer us great support here, it's quite reasonable that
he'll reject this, though I have added it as a Wishlist item:
http://rt.cpan.org/Public/Bug/Display.html?id=43943
I could implement this with with INIT and using MRO::Compat and
mro::get_pkg_gen() to determine when a method cache is invalid (that way, you
can cache whether a method overrides something and refresh the cache as
needed), but it fails with AUTOLOAD and other methods of delayed installation
of methods into a symbol table. Also, INIT will fail with persistent code such
as modperl.
C++ handles this by requiring methods which can be overridden to be declared as
virtual. Unfortunately, it doesn't provide any syntax in the derived classes
to make it clear you're overriding a method. This is a huge pitfall in C++
because if Child and Parent both provide munge and acquire methods and the
parent class only marks munge as virtual, you might accidentally call
Parent::acquire if you have the wrong pointer type:
http://developer.kde.org/~wheeler/cpp-pitfalls.html
C# is a bit more sane about this. Parent classes must declare overrideable
methods as virtual and child classes must mark methods as override or new
(this hides the parent method even if it's not declared virtual):
http://www.akadia.com/services/dotnet_polymorphism.html
C# is great in this respect because you can look at a definition of a method
and get a lot more information about what's going on.
I suspect we'll have to wait until Perl 6 to get this handled cleanly.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Module for detecting is a method is overridden
I want to write a module which allows me to quickly detect if a method is
overriding a parent class method (I already know about the method cache
invalidation problem).
Potential uses would be for something like this:
use Attribute::Override;
use parent 'Some::Class';
sub foo :override{...} # fails if it doesn't override
sub bar {...} # fails if it does override
Or:
# needs to
use Method::Override;
Method::Override::overriden(qw/foo/); # must be done after compilation
That can solve nasty problems where the developer accidentally overrides a
parent method but doesn't realize it. Still trying to figure out a good
interface, otherwise it will never get used (unless it's built in to the
language, I suspect it will never get used anyway, but what the heck :)
Suggestions?
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
- Original Message
From: Aldo Calpini d...@perl.it
Ovid wrote:
Readonly constants are just easier to use and have fewer gotchas.
they have indeed, when you need to access the constants from outside of the
module they are declared in (which is a pretty common case).
It also used to be very common not to use strict or warnings. This doesn't
mean it's a good thing. The module in question should provide a sub or method
to provide access to this data. Java programmers learned long ago not to let
people tough their privates, Perl programmers should learn the same thing.
(For example, when the constant is computed rather than declared, wrapping it
in a sub saves a *lot* of grief -- if you've done that up front and not forced
people to change their APIs).
If you *must* use globals, it's certainly a good thing that they're read-only
but at the very least, do it sanely:
package Some::Module;
use Readonly;
Readonly our $foo = 3;
use Exporter 'import'
our @EXPORT_OK = ('$foo'):
Note that we've been forced to switch from 'my' to 'our' in the Readonly
variable, but now the calling code doesn't need a fully-qualified package name:
use Some::Module '$foo';
print $foo;
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Perl Critic and (honest) hash references
- Original Message
From: Roger Hall raha...@ualr.edu
Personally though, I wouldn't create an object unless there were methods
(which there are not in this case). Without methods, an object just seems
like a too-fat hash to me! :}
Mostly agreed. Objects should be about responsibilities (behavior) and not so
much about state (data). That being said, hashes are notorious for
$gimme-{feild} (note the misspelling) or $current-{ip_address} = apples
(wrong kind of data) and objects can help there, but that's using objects to
overcome Perl's type limitations. Seems a bit heavyweight at times, really.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: ARGH! (was FW: Perl Critic and (honest) hash references)
From: Bill Ward b...@wards.net
This gives you quite friendly policy identifiers
[ValuesAndExpressions::ProhibitConstantPragma] Pragma constant used
at line 22, column 1. (Severity: 4)
What's wrong with 'use constant'?
Well, nothing's wrong with it. It does, however, get clumsy in some cases.
For example:
use constant FOO = 3;
print $data-{+FOO};
print We have @{[FOO]} widgets;
# or
print We have .FOO. widgets;
Versus:
use Readonly;
Readonly my $FOO = 3;
print $data-{$FOO};
print We have $FOO widgets;
Readonly constants are just easier to use and have fewer gotchas.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Class::Sniff - Find code smells in class hierarchies
I'm sure I'll add more later, but for now, I've just uploaded Class::Sniff to
the CPAN and it's also on github
(http://github.com/Ovid/class--sniff/tree/master).
If anyone wants to bang on it, that would be great. I'd be interested to know
if it works on 'real' code :)
my $sniff = Class::Sniff-new({
class = 'My::Customer',
ignore = qr/DBIx::Class/, # optional
});
foreach my $method ($sniff-unreachable) {
print Cannot reach method ($method)\n;
}
# useful if you find yourself overriding methods you didn't expect to override
my $overridden = $sniff-overridden;
while (my ($method, $classes) = each %$overridden) {
my $classes = join ', ' = @$classes;
print Method ($method) is defined in ($classes)\n;
}
It assumes Perl's standard left-most/depth-first inheritance search order, but
you can override that with the 'paths' method. It does a lot more than what's
listed above and is fully documented, including explanations of various OO
'code smells'.
Note that if you are not using multiple inheritance, you won't have any
'unreachable' methods.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
use Test::More no_plan = $plan;
In the developer release of Test::Simple, Test::Builder has been altered to die if you have any arguments after 'no_plan'. This means that some previously passing tests will fail. In fact, there are two test programs in Moose 0.57 which have this and thus fail to pass: use Test::More no_plan = 1; I've recommended that we warn instead of croak as I don't know how widespread this problem is (I'd just fix it, but I don't have external Subversion access at work). I expect we'll fix this, but for the time being, please don't use 'no_plan = $plan' in your tests. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Need help improving my Kwalitee
--- On Wed, 23/7/08, Burak Gürsoy [EMAIL PROTECTED] wrote: I'm not interested in Module::Build. I've checked your Makefile.PL and you're not doing anything special with it (like subclassing or XS stuff, etc.), so it'll be straight forward to add Module::Build support to your module. And since M::B is in core starting with 5.10, I think it's the way to go (although I know there are haters of M::B in the Perl world). If we had started with Module::Build from day one instead of ExtUtil::MakeMaker, life would be a better place as many MB issues would have been long resolved[1]. Regrettably, this isn't the case, so people ignore the theoretical technical superiority of the MB idea and instead focus on the fact that it doesn't do what they want. We'll ignore the fact that many features that people want for EMM have not been added because while they're trivial in MB, they're a nightmare for EMM[2] This has now led to others building competing systems which support different features and people are falling back to EMM as safe, but if I have complex build needs, it's anything but :( Cheers, Ovid 1. 'PREFIX', for example, has been the bane of many developers who work on build systems (there are plenty of us), but people who consume the modules generally don't care that it's broken because *they're* not the ones who have to do the hard work. http://www.perlmonks.org/?node_id=458436 (that's from Schwern and the language is not safe for work). 2. For each OS and OS version, take the number of different make programs and their different, subtly incompatible formats and features and you can get an idea of the scope of the problem. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Exporter::Safe?
--- On Sat, 19/7/08, Bill Ward [EMAIL PROTECTED] wrote: I can't think of any reason you would want to use an imported subroutine as an object method. Class::Trait Moose::Role mixin Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Proposal: Test::Refcount
--- On Mon, 14/7/08, Ivan Wills [EMAIL PROTECTED] wrote: Is this Devel::Refcount really necessary, given how easy it is to build using B::SV-REFCNT ? Plus, the more levels of code, the more difficult it is to ensure the count is correct. I see your point although I would contend that a Devel::Refcount module would be useful even if Test::Refcount didn't use it as knowing about B::SV-REFCNT is not easy. The B:: namespace not a place I would think that may perl programers would go and try searching on CPAN for reference counting and you will have a hard time finding out about B::svref_2object call let alone the REFCNT parameter. ++ The B modules are incredibly powerful, poorly documented pieces of crap. They may be great, but without documentation on how to use that speedboat, it's so much scrap metal. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Proposal: Test::Refcount
--- On Tue, 15/7/08, Paul LeoNerd Evans [EMAIL PROTECTED] wrote: The B modules are incredibly powerful, poorly documented pieces of crap. They may be great, but without documentation on how to use that speedboat, it's so much scrap metal. So... is this a vote in favour of better docs, or a wrapper module to hide the magicness? People who have the ability to document the B:: modules (not me) don't seem to have the inclination and I doubt this will change any time soon. (This frustrating, but hey, it's free software and I'm grateful there's at least *something* there). So I'd vote for the wrapper. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Exporter::Safe?
--- Hans Dieter Pearcey [EMAIL PROTECTED] wrote:
never does anything to the importing package
use Foo::Bar as = Bar;
plops a constant function Bar into your package. The constant is an
object on which you can do
Bar-some_function(@args)
and it is the equivalent of calling
Foo::Bar::some_function(@args)
In my TODO is an entry for implementing this for Sub::Exporter.
You don't even need to use AUTOLOAD:
* create Some::Long::Generated::Package
* import symbols from Foo::Bar into SLGP, wrapping each with
sub { shift; $original_code-(@_) }
* export Bar() into the calling package
sub Bar () { Some::Long::Generated::Package }
This is sort of on the CPAN now.
use aliased 'Some::Long::Module::Name::For::Customer';
my $customer = Customer-new;
It's moderately popular and people are quite happy with it (at least
from the feedback I've gotten). Though I'm rather interested in this
take on the idea.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Personal blog- http://publius-ovidius.livejournal.com/
Tech blog- http://use.perl.org/~Ovid/journal/
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Official Parrot Wiki - http://www.perlfoundation.org/parrot
Exporter::Safe?
Buried deep within some code, someone used a module (Test::Most 0.03) which exports a 'set' function. They weren't actually using that module. It was just leftover cruft. Unfortunately, the parent class of that module inherited from Class::Accessor. Test::Most exports 'set' and Class::Accessor calls a 'set' method. Oops. I'm trying to think of the best way to deal with this. My first thought is to create a drop in replacement for Exporter which will not export a function if caller-can($function) *unless* the person explicitly lists it in the import list with a unary plus: use Test::Most plan = 3, '+set'; Are there better strategies? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Exporter::Safe?
--- Ovid [EMAIL PROTECTED] wrote: I'm trying to think of the best way to deal with this. My first thought is to create a drop in replacement for Exporter which will not export a function if caller-can($function) *unless* the person explicitly lists it in the import list with a unary plus: Which fails if the function isn't defined when Test::Most is used. A CHECK block might help, but I suspect that breaks under test aggregation. Related issues are at http://use.perl.org/~Ovid/journal/36738 Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Andy differentiation
--- David Nicol [EMAIL PROTECTED] wrote: Armstrong: Hexten, London. Actually, Cumbria, just south of Scotland. Not London :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Depending on external tools (2)
--- Johan Vromans [EMAIL PROTECTED] wrote: I have an app that works with PostgreSQL. It depends on DPD::Pg. So far, so good. However, the requirement that DBD::Pg is installed is by no means a guarantee that there is a database server around. And if there is, the user running the CPAN test may nog have (sufficient) access to this database. What would be a good means to arm the test scripts against this? You might want to take a look at Object::Relation. There is a Object::Relation::Setup class which, if you're using a Postgres database, uses Object::Relation::Setup::PG: http://search.cpan.org/dist/Object-Relation/lib/Object/Relation/Setup/DB/Pg.pm Internally, you'll want to check out the rules method. This is a state-machine driven method of validating dependencies for Postgres setup, such as does the database exist, does the user exist, does the user have sufficient permissions, etc. Might take a bit of getting used to, but it's pretty damned powerful. You can see an example of a graphed version of that state machine in Theory's journal: http://justatheory.com/computers/programming/perl/fsa_rules_graph_improved.html Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: EUMM and Module::Build installations - Oh God, Help!
--- David Golden [EMAIL PROTECTED] wrote:
I think that if you 'use lib qq{$ROOT/lib/perl5}' then the
architecture directory gets added automatically. (According to
'perldoc lib').
Yes, that's correct. I still don't think those belong in the same
directory, but that's just me :)
Maybe I just don't understand what you're trying to do well enough to
see why architecture specific directories are a problem. (XY
problem?)
It might *be* an XY problem. We already has a directory layout for
external modules and we were trying to get CPAN to install to that
layout rather than try reorganize all of our dependencies and hope that
nothing broke.
As note, we went with the reorganization, despite other useful
suggestions from here. Going the 'INSTALL_BASE' route was a one-time
pain (we hope :)
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
EUMM and Module::Build installations - Oh God, Help!
At work, we ship our dependencies with our code. As it turns out, everyone installs these dependencies in slightly different ways because no one can *quite* figure out how to configure CPAN to handle this for us. What we would like, and having it work for both EUMM and Module::Build, is to make our installation look like this: $ROOT/lib/ $ROOT/arch/lib $ROOT/bin/ $ROOT/man/man1/ $ROOT/man/man3/ (We've gotten close to the above, but the .packlist files keep getting shoved in /opt/csw/lib/perl/site_perl/auto/... and CPAN screams at us). Is there some script out there which will properly configure CPAN::Config to give us fine-grained control over all of this? Is there something I've missed in the above? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: EUMM and Module::Build installations - Oh God, Help!
--- David Golden [EMAIL PROTECTED] wrote:
$ROOT/lib/
$ROOT/arch/lib
$ROOT/bin/
$ROOT/man/man1/
$ROOT/man/man3/
Is this not just --install_base (M::B) or INSTALL_BASE (recent
EU::MM)?
No, --install_base looks like this:
$ROOT/lib/perl5/$Config{archname}
$ROOT/lib/perl5
$ROOT/bin
$ROOT/man/man1
$ROOT/man/man3
Which means that you have architecture specific stuff in your lib/perl5
directory. So for a mac you might have something like:
$ROOT/lib/perl5/darwin-2level/Encode/Alias.pm
I don't know that someone could get Perl to try to load a package named
package darwin-2level::Encode::Alias since that's not a legal package
name, but I don't know that all architectures could have names which
aren't legal package names. I'd prefer them to be in separate
directories.
That being said, we've bit the bullet and rearranged our libraries to
fit '--install-base'. There's some short term pain there, but in the
long run, it seems like a win.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Installing tarballs with CPAN.pm
Quite often I find myself in the position of having a tarball that I'd like to install with CPAN.pm. There are two reasons I'd like to do this: * Let CPAN.pm find and install dependencies for me * Take advantage of my highly customized CPAN installation requirements In other words, I'd like to do this: $ perl -MCPAN -e shell CPAN: File::HomeDir loaded ok (v0.65) cpan shell -- CPAN exploration and modules installation (v1.9102) ReadLine support enabled cpan[1] install ./Highly-Experimental-0.01.tgz I've looked for a hack that would let me do this, but no luck. Is there a way to do this that I just haven't seen in the docs? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Installing tarballs with CPAN.pm
--- jonasbn [EMAIL PROTECTED] wrote: Hi Ovid, We need what you describe, I really like the idea. An alternative solution for now might be to stick the tar-ball in your mini-cpan mirror if you have one. Actually, someone on Perlmonks just pointed me to a section of the docs I missed: http://search.cpan.org/dist/CPAN/lib/CPAN.pm#Integrating_local_directories So you should be able to: tar zxf Some-Module-0.1.tgz cd Some-Module-0.1 cpan . :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: With the Macrame macro system, Perl may now be a Lisp.
--- Guy Hulbert [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 15:26 -0600, Jonathan Rockway wrote: BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Academic thinking again. CGI is highly successful. It's highly successful in the way that COBOL* is highly successful: for a while it was the main game in town and if you wanted to play, that's what you played. Now that CGI.pm is old and outdated (even Lincoln Stein has admitted that he'd write it differently today), we're largely stuck with it for legacy issues. Inertia is not the same thing success. Cheers, Ovid * I'm an ex-COBOL programmer and I know exactly what I'm talking about here. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: distributed/centralized META.yml data
- Original Message From: Andy Lester [EMAIL PROTECTED] To: Eric Wilhelm [EMAIL PROTECTED] Cc: module-authors@perl.org Sent: Tuesday, October 30, 2007 2:39:01 PM Subject: Re: distributed/centralized META.yml data The trouble with ad-hoc is just that it tends to *never* get formalized (i.e. never gets centrally documented, becomes discoverable, appears in books, etc.) The trouble with planned soluttions is that it tends to *never* get implemented. Lots of talking, lots of ideas, precious little implementation. I agree completely with this. I see it all the time and it's a huge frustration. I'm not afraid of iterative solutions. It doesn't bother me to think that I might implement something today, just to get it out there, and then have to revert it. That being said, iterative solutions are fine on a personal project or when working on code for a company. They can be far more problematic when they're planned for a huge, real-world user base. If they start out good, lots of people can buy into the first solution and remain stuck on a suboptimal path. Anyone remember how COBOL was supposed to be an intermediate step and a proper language released later on? Grace Hopper reportedly said that she would have done things much differently if she new the next version was never coming out. (I could also make snarky comments about the crap we call SQL and how the buy-in to this suboptimal solution has effectively destroyed a lot of real database work, but I won't :) Frankly, I'd suggest waiting a while before pulling the trigger and then if nothing manifests (which I'm guessing it won't), then go ahead. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: lambda - a shortcut for sub {...}
--- Eric Wilhelm [EMAIL PROTECTED] wrote: http://search.cpan.org/~ewilhelm/lambda-v0.0.1/lib/lambda.pm Combined with that vim shortcut, this is just too cool :) I'd probably have put it in the Acme:: namespace, though. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: lambda - a shortcut for an apology
--- Ovid [EMAIL PROTECTED] wrote:
Well, if you want to use it in your own code and your work's code,
that's fine (because I'm sure you find typing CONTROL-SHIFT-EL so
much
easier than sub {} :) but if it shows up in your CPAN modules, you
might get a few complaints since this sugar, while a really nifty
hack,
adds nothing complex but does screw up older editors and will confuse
the heck out of a lot of maintenance programmers.
You know, I was privately called on this and I was wrong. Eric, I'm
sorry and I shouldn't have said this. At this point on the CPAN, it
really doesn't matter what goes out there. I really *do* like this
hack and who am I to say what namespace it should be in?
So my apologies for taking such a negative view. I'm sorry if I gave
offense.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: lambda - a shortcut for sub {...}
--- Eric Wilhelm [EMAIL PROTECTED] wrote:
And why do we have an 'eq' operator instead of 'equals' ?
IMO, shortcuts for typing long things will lead us to Eclipse.
lambda - a shortcut for sub {...}
my $code = #955; {...}; # instead of sub {...}
;)
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
--- Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: Hmm.. As is, relative.pm already allows you to do that (thanks to Ken Williams' suggestion): package My::Enterprise::Framework; use relative; my $Customer = import relative qw(Report Customer); my $customer = $Customer-new($id); That is, import returns the full names of the successfully loaded modules in list context, or the last one in scalar context. Is this sufficient or did I misunderstand you? Ah, I didn't notice that. I think that would be fine. The only caveat being that this is lexically scoped, but I don't *think* there is problem there. Thanks for a nice module! Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
* Eric Wilhelm [EMAIL PROTECTED] [2007-10-09 01:55]:
This changes the require() on Foo::Report and Foo::Customer to
run-time though, right?
use Devel::BeginLift qw( require );
Cute trick, but I wondered if that would globally break require.
#!/usr/bin/perl -l
use strict;
use warnings;
use Devel::BeginLift qw(require);
require Data::Dumper;
BEGIN {
no warnings 'once';
print $Data::Dumper::Indent;
}
Seems to have no impact on require at all. I suspect that's because
it's not a subroutine.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
(OT) Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
--- Jonathan Rockway [EMAIL PROTECTED] wrote:
OT, but 'ok.pm' is quite nice:
use Test::More tests = 1;
use ok 'My::Module'; # test runs at compile time
Oh, I really like that, but it still causes an issue for me. You see,
a lot of what I do is stuff like this:
my $CLASS;
BEGIN {
$CLASS = 'Customer';
use_ok $CLASS or die;
}
can_ok $CLASS, 'new';
ok my $cust = $CLASS-new, '... and we can call it';
isa_ok $cust, $CLASS, '... and the object it returns';
This means that if I need to refactor classes to better namespaces, I
merely change the $CLASS = line. With the lovely ok.pm module, I
still have the following clunky construct:
my $CLASS;
BEGIN {
$CLASS = 'Customer';
}
use ok $CLASS or die;
can_ok $CLASS, 'new';
ok my $cust = $CLASS-new, '... and we can call it';
isa_ok $cust, $CLASS, '... and the object it returns';
Those BEGIN blocks really annoy the hell out of me at times :(
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: S/SA/SAPER/relative-0.02.tar.gz (feature request)
--- Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: Hello, The version 0.02 of relative.pm is now available on the CPAN. Thanks to everybody who suggested improvements. (And it still works on Perl 5.004 :-) I like the idea of this module. Lots of people like the idea of 'aliased'. Would it be worth combining the two? use My::Enterprise::Framework; use relative -aliased = qw(Customer Report); # instead of: # my $customer = My::Enterprise::Framework::Customer-new($id); # use: my $customer = Customer-new($id); http://search.cpan.org/dist/aliased/ Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Class::Dataset
--- Ovid [EMAIL PROTECTED] wrote: I want a generic dataset reporting tool which allows me to: * Specify a raw attribute to be rendered * Specify virtual attributes to be calculated * Validates that added records match attributes * Optionally accepts a TT template for custom rendering FYI: for any who might be curious, Data::Report does most of what I'm looking for. Searching for 'report' should have been obvious. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: [ANNOUNCE] Test::Builder/More/Simple 0.72
--- chromatic [EMAIL PROTECTED] wrote: On Wednesday 19 September 2007 22:46:19 Ovid wrote: This has happened a couple of times now. Why don't you use release devel versions so that these issues become less serious in the future? In your experience, do devel versions get the kind of testing that would catch these issues sufficiently? In my experience, they don't. For something as high profile as Test::Simple, it would get much more exposure than most modules. Plus, there wasn't much in the changelog which suggested this was a rush OMG Must Deliver Now sort of change (it had been six months since the last release). And it would be nice to have this run against a substantial portion of a minicpan install since breaking the toolchain is a very, very bad thing to do (as Schwern as *repeatedly* pounded into my head :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: [ANNOUNCE] Test::Builder/More/Simple 0.72
--- Michael G Schwern [EMAIL PROTECTED] wrote: Because of this I'm TEMPORARILY rolling the fix back at least a week to give CPAN authors a little breathing room to make their fixes. The fix is usually to plan in a BEGIN block. This has happened a couple of times now. Why don't you use release devel versions so that these issues become less serious in the future? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Module Proposal: Package::Data::Inheritable
Oops. Sent privately instead of to the list. Resending.
--- nntp.perl.org [EMAIL PROTECTED] wrote:
I've written a module to deal with the issue of inheritable class
data (yes, yet another one).
What's peculiar with it is that it doesn't rely on accessor methods.
After declaration, you can use the variables just like any other
package
variable but you can inherit and override those variables in other
packages/classes.
Hi Giacamo,
Hey, this idea sounds very cool, but unfortunately, it's a bad idea
(conceptually similar to Java's mistake of allowing public properties).
Here's an example, using some pseudo-code which assumes that Universe
exports class data named '$pi':
use Universe ($pi);
my $universe = Universe-new('standard');
print $pi;# 3.14 ...
$pi = -13;# What?
print $pi;# -13
The problem with public properties instead of methods is that you
cannot easily validate them at the time of setting the value. Sure,
you can tie the variable, but why go through all of that work for a
single value? Just make a setter/getter and you can validate it.
Admittedly, Class::Data::Inheritable doesn't validate it, but you can
do this:
use base 'Class::Data::Inheritable';
__PACKAGE__-mk_classdata( _pi = 3.14 );
sub pi {
my $self = shift;
return $self-_pi unless @_;
my $pi = shift;
# make sure $pi is a valid number or die, die, die
$self-_pi($pi);
return $self;
}
Now you get nice safety and don't have to worry about things. Later,
if you find your universe needs to calculate the value of pi
(presumably by making an RPC call to another universe), you still have
a nice method encapsulating this and don't have to change the public
interface.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: Module Proposal: Package::Data::Inheritable
--- Giacomo Cerrai [EMAIL PROTECTED] wrote:
With accessor methods this would be considerably more verbose:
foo({param = $val,
fields = { $SomeClass-FIELDNAME1 = $val1,
$SomeClass-FIELDNAME2 = $val2,
...
$SomeClass-FIELDNAMEn = $valn,
},
});
...
foreach my $field ($SomeClass-FIELD4, $SomeClass-FIELD2, ...,
$SomeClass-FIELD10) {
...
This becomes quickly unreadable and is not lazy.
Furthermore every fieldname access is a method call which is too much
overhead, especially when you have many fields to deal with.
A couple of problems here.
Yes, methods can sometimes be more verbose than variables, but Java
made a huge mistake by violating encapsulation. However, at least in
Java you get a little bit of type safety (not much, but some).
It's important to optimize for correctness first. Readability *must*
come after correctness because if a program is incorrect, whether or
not it's legible is small consolation.
Also, if you're doing a huge amount of work with basic getter/setters,
perhaps revisiting your object heirarchy is worthwhile. The more I've
learned about OO, the more I've learned that it's about behaviors, not
about data. Looking at data instead of behaviors can really hamper
effectiveness in OO systems because you become tied to the data when
what you really want is modeling of your problem domain's rules.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
Re: Module Proposal: Package::Data::Inheritable
--- Giacomo Cerrai [EMAIL PROTECTED] wrote: Just one note. It's not clear from my post, I should have put a 'package SomeClass' or $self-foo but the code above is in-class code, not meant as client code (although you cannot prevent that). Ah, this is for internal use only? OK then. The downside significantly less than I thought. Feel free to disregard a lot of what I said :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: How do I express a dependency on a Perl version?
--- David Golden [EMAIL PROTECTED] wrote: In Build.PL, add perl to the requires list. In Makefile.PL, add require 5.008 to the top of the Makefile.PL Out of curiosity, why is require 5.008 not a suitable option for Build.PL? Does it track this as metadata and report on it? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: what's the right way to test a source filter?
--- David Nicol [EMAIL PROTECTED] wrote: so I am closer than ever to releasing my way-cool source filter module, which is based on Filter::Simple. Big question: how do I write the test script? It depends upon what you're filtering. In Sub::Signatures, you can have regular subroutine and method signatures and this makes using it with tests trivial. If it might impact the test code or you want to minimize this risk then have the filtered code in t/lib or t/data and have your test code 'use' it, thus ensuring a clean separation. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: Please let me have co-maintainership of XML-SemanticDiff
- Original Message From: David Landgren [EMAIL PROTECTED] That's for sure. My only question concerns the license. I see that the previous version was licensed under the same terms as Perl itself. Will you continue to do as well, or do you plan to change it to your UCLA license? Excellent question! Every time I see Yet Another License popping up with an author who claims that It's OK, it's better!, I just want to scream. I don't have time or patience for this and if I have the slightest bit of doubt, I'll chuck the module and reach for one with the standard Perl licensing. (This is not an invitation to defend ANY other license. I have too many things to do and I don't want to be burdened with someone else's pet crusade) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Module::Install reporting ARRAY(0x82c3dd8) ...missing
- Original Message
From: Bill Moseley [EMAIL PROTECTED]
On Mon, Jun 18, 2007 at 11:26:45AM +0100, Paul LeoNerd Evans wrote:
My main objection to Module::Install is that it lives in the distribution
itself, rather than being out-of-tree, living on the target system.
snip
Moreover, they contain a snapshot of
whatever version of M::I was current at the time it was built, or, maybe,
whatever version the module's developer had at the time.
Yes and no. At least you know the version included worked -- where an
earlier or later version might not.
You only know that this version worked on the module author's machine with the
module author's build and environment. And even then you don't know that
because they might have left out a 'requires' for a module they have installed.
2) A way to say some modules are recommended but not required.
Do any installers support that?
Sure. From the Module::Build Build.PL file :)
recommends = {
'Archive::Tar' = '1.08',
'ExtUtils::CBuilder' = 0.15,
'ExtUtils::Install' = 0.30,
'ExtUtils::ParseXS' = 1.02,
'Pod::Readme' = 0.04,
'Module::Signature' = 0.21,
'version' = 0.661,
},The Module::Build::Authoring docs specifically states that
this key is for versions of modules that are recommended to provide enhanced
functionality.
Cheers,
Ovid
Marcus Thiesen's modules
Hi all, Per an email exchange with Marcus Thiesen, he has confirmed that he is no longer maintaining his modules, he will be filing meta bug reports to all modules stating this fact and he's given me permission to forward along the following snippet: actually, getting the concrete question I guess the answer is no. I don't have enough spare time to work on my modules anymore. I think I have to orphane them somewhere publicly. The affected modules are: - CPANPLUS::Shell::Curses - Curses::UI - Curses::UI::Mousehandler::GPM - GraphViz::ISA::Multi - Text::Compare - XML::OPML::SimpleGen - XML::RSS::FromAtom If anyone is interested in taking these over, that would be useful -- particularly Curses::UI, because I'm using right now :) What's the procedure on this? I can never remember. The CPAN FAQ covers when an author has been unresponsive (http://www.cpan.org/misc/cpan-faq.html#How_maintain_module), but Marcus has been quite helpful in explaining that he doesn't have the time for this. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: LISP module from CPAN
--- David Nicol [EMAIL PROTECTED] wrote: Ever since reading Hackers and Painters http://www.amazon.com/exec/obidos/ISBN=0596006624/tipjartransactioA I've been defending Perl is a LISP! (which is actually quite easy, because nobody knows what I'm talking about) And for those who have not read the brilliant rebuttal to the Hackers and Painters article: http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Test failures - I can't work out why
--- Eric Wilhelm [EMAIL PROTECTED] wrote: but for the most part it is a happy little bubble. When I lose that abstraction layer, I guess I'll have to go sell fishing reels, start a night club, join a monastery, or etc. Hmm, let's see. 'grep' from Portland.pm gave up IT to sell fishing reels. Jamie Zawicky started a night club and Randal Schwartz has DJd at them. Many of us are members of the Perlmonks Monastery. I guess we've all lost that abstraction layer ... :) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Test failures - I can't work out why
--- Keith Ivey [EMAIL PROTECTED] wrote: A. Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2007-05-02 12:40]: Jamie Zawicky Zawinsky. Zawinski, actually -- or is it Zawodny? Nope. Aristotle's right. I definitely meant Zawinsky. He runs the DNA Lounge (http://www.dnalounge.com/). Their music seems awesome. If I ever get to that part of the world, I might just drop in. (Zawodny works for Yahoo!) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Test failures - I can't work out why
--- Keith Ivey [EMAIL PROTECTED] wrote: Yeah, Zawodny was a joke. But JWZ is still Zawinski, not Zawinsky. Gah. Kill me now, please. -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Module name - smoke testing automation
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
makes no effective difference. Iâd attack this directly by
cleaning up $ENV{PATH}:
use Config;
use File::Spec::Functions;
use File::stat;
use Fcntl qw( :mode );
$ENV{PATH} = do {
my $sep = $Config{path_sep};
join $sep, (
map { /(.*)/ }
grep { ! stat($_)-mode S_IWOTH }
grep { file_name_is_absolute( $_ ) }
split( /\Q$sep/, $ENV{PATH}, -1 ),
);
};
Turns out this solves an issue I have at work. There were two issues I
uncovered.
1. The server I tested this on had one entry in the PATH which didn't
exist on the server, so I first check to see if stat($_) returns a true
value.
2. There was a precedence problem. The not (!) binds tighter than the
bitwise and (), so parentheses were needed.
$ENV{PATH} = do {
my $sep = $Config{path_sep};
join $sep, (
map { /(.*)/ }
grep { stat($_) !( stat($_)-mode S_IWOTH ) }
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH} ),
);
};
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Module name - smoke testing automation
--- Ovid [EMAIL PROTECTED] wrote:
$ENV{PATH} = do {
my $sep = $Config{path_sep};
join $sep, (
map { /(.*)/ }
grep { stat($_) !( stat($_)-mode S_IWOTH ) }
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH} ),
);
};
Ugh. I hated my double call to stat().
$ENV{PATH} = do {
my $sep = $Config{path_sep};
join $sep, (
map { /(.*)/ }
grep {
local $_ = stat $_;
defined !( $_-mode S_IWOTH )
}
grep { file_name_is_absolute($_) }
split( /\Q$sep/, $ENV{PATH}, -1 ),
);
};
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Module name - smoke testing automation
--- A. Pagaltzis [EMAIL PROTECTED] wrote: Note that `local $_` has issues when tieing or other magic are involved. If you want to topicalise something, use `for` instead. Thatâs not viable in this case, though, since `for` doesnât return a well-defined value and you need that for `grep`. Better just use a lexical variable. Thanks for this and the other comments. Great points. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Module name - smoke testing automation
--- Dave Rolsky [EMAIL PROTECTED] wrote:
Well, it's a little more programmatic than that. The svn up part is
dirt-simple, but doing something like running svn info $uri against
the repo uri to get the last changed date requires some code and
regular expressions and whatnot.
Out of curiosity, what's your cross-platform way of figuring out the
full path to the svn executable? Just doing system('svn', 'info',
$uri) can get you an Insecure $ENV{PATH} (or something like that)
when running in taint mode.
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Another non-free license - PerlBuildSystem
Being an *extremely* political creature, I'm sorely tempted to wade into this mess, but I won't. Can we just agree to stick to the license's suitability for the CPAN? Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Another Bantown License
--- imacat [EMAIL PROTECTED] wrote: So, what about this SNMP::APCUPS? It uses the same Bantown lincense. Shall it be removed, too? It should be. I'm pretty sure that the license is invalid because you can't require someone to commit crimes as part of a license agreement, but even despite that, I find parts of the license to be a tad offensive. Also, distributing a license which suggests that people engage in ... * 18 U.S.C. § 1751 Presidential and Presidential staff assassination, kidnapping, and assault ... could very well be illegal in the US as threatening the President is a crime. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Looking for a module name
--- Eric Wilhelm [EMAIL PROTECTED] wrote: BTW, before this goes on CPAN, I would like to cast my vote against the dromedaryCased methodNames. Please, use lowercase_with_underscores. ++ More than once I've thought about writing Acme::NowYouUnderstandWhyYouNeedToFixTheHorribleMethodNamesBeforeYouGoBlindYouSillyGit. Others are free to steal that module name if I never get around to writing it :) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: CGI::Simple
--- Andy Armstrong [EMAIL PROTECTED] wrote: On 10 Jan 2007, at 04:07, Ken Williams wrote: Wow, that's the smoothest I've ever seen one of these transfers go. A useful module, an obviously deadbeat developer, an eager volunteer (and only one!), it's the perfect storm. I think the term 'deadbeat developer' might be a little harsh for someone who obviously invested considerable time, care and skill into producing a module that many have since found useful :) While the term might be a little harsh, I do have to agree with Ken about how ridiculously smooth this went. I simply feared we'd have another module go down in oblivion :) Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
CGI::Simple
Has anyone heard from James Freeman, the maintainer of CGI::Simple (http://search.cpan.org/dist/Cgi-Simple/)? It's not been updated in a couple of years, the outstanding bugs appear to mostly be related to the same issue, and I tried emailing him about this using the contact email he provided at http://www.perlmonks.org/?node=tachyon. I'm not particularly keen on taking over this distribution, but he's not fixing this bug or even responding. He also notes that Perl is a fond corner of [his] past, suggesting that unless someone snags CGI::Simple, this very popular (and useful!) module will not be fixed. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: no contact with author
--- Darek Dwornikowski [EMAIL PROTECTED] wrote: Hi, I am using a module from CPAN, but it lacks some functionality, so I added them. The problem is that there is no contact with author, I sent him emails twice (6months ago and 2weeks ago). A guy from [EMAIL PROTECTED] (integral), adviced to write here. Thoughts: 1. I can understand your not wanting to mention the name of the module, but we might be able to provide more help if we know it, particularly if someone on this list is aware of what happened. 2. You could fork the module on the CPAN (which means maintaining it, something you might not want to do). 3. You could fork the module for your company's internal use, which I know many programmers do. 4. You could tell us what functionality you added. I do know that some authors just won't respond to what they consider unimportant or bad requests (I'm not saying your changes are unimportant or bad; the author might just see them that way.) I might add that if a fork happens, many people might be happy to see the fork on the CPAN. The theory is that many people can benefit. However, that means you have to maintain it and that can be more trouble than it's worth. More than once I've begged people for patches, only to be ignored. Plenty of other authors have had the same experience. Maintaining modules can be frustrating. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Looking for David Shultz
Hi Peter, I know a David Shultz and I think he has an interest in that area. Whether he's the same David, though, I've no idea. However, I just dropped him an email and listed your name and email address in it. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Attributes in Class::Trait
Hi all,
Some folks are happy with my Class::Trait module, but not entirely happy with
the the fact that private trait methods currently must be declared as lexical
methods:
my $meth = sub { ... };
sub foo { shift-$meth }
Praveen Ray has sent me a patch which lets authors do this:
sub meth : private { ... }
sub foo { shift-meth }
That's a much nicer syntax but I also realize that a number of folks aren't
keen on attributes. This attribute is read by use attributes
(http://search.cpan.org/src/NWCLARK/perl-5.8.8/lib/attributes.pm), a nice, core
module, but I'm wondering if there are any pitfalls here I should be aware of?
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Integrating Test::Run with Module::Build
- Original Message From: Shlomi Fish In other news, Test::Run now makes use of TAPx::Parser to parse the TAP. It still collects the statistics on its own, because I couldn't remember whether TAPx::Parser does that or not, and it was too much work to do at one time. Depends upon which statistics you want. If you want aggregate statistics of various test runs, use TAPx::Parser::Aggregator: http://search.cpan.org/dist/TAPx-Parser/lib/TAPx/Parser/Aggregator.pm use TAPx::Parser::Aggregator; my $aggregate = TAPx::Parser::Aggregator-new; $aggregate-add( 't/00-load.t', $load_parser ); $aggregate-add( 't/10-lex.t', $lex_parser ); my $summary = 'END_SUMMARY'; Passed: %s Failed: %s Unexpectedly succeeded: %s END_SUMMARY printf $summary, scalar $aggregate-passed, scalar $aggregate-failed, scalar $aggregate-todo_failed; The above assumes that $load_parser and $lex_parser are parsers which have already finished parsing. You can also look at the various tprove* files in examples/ for more usage. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Give up your modules!
- Original Message From: Ken Williams [EMAIL PROTECTED] Having a name and shame mentality about this is IMO wrong. I hope you're not saying I suggested that. I did not name anyone. I didn't ask for a list of modules whose authors we should hunt down. I only asked for those authors to find *some* way of ensuring that their users can get support if the author does not have the time or inclination to do so. It's not too hard to find widely used modules which for various reasons, would be hard to switch away from yet are effectively abandoned (which is as close as I'll come to naming and shaming). That list should be left as a *private* exercise for the reader. Cheers, Ovid
Re: Give up your modules!
- Original Message From: imacat [EMAIL PROTECTED] On Mon, 14 Aug 2006 09:19:15 -0500 Andy Lester [EMAIL PROTECTED] wrote: (Re-making my mental note to transcribe Stop saying 'script') Sorry I might be off-topic, but why Stop saying 'script'? I have searched the google and found nothing on this. I thought script is the formal term to referring them from the beginning, and throughout my documentation. If someone could provide more information or relative resources on this issue, I would be very appreciated. Because Perl programs are programs. I get tired of people dismissing what I do for a living as 'mere scripting' even though there's a darn good chance I've worked on systems (in Perl) far larger than many which they have. By referring to Perl programs as scripts, even if they're short programs, we reinforce the false notion that Perl is some toy language. Heck, if I found out a C programmer hacked out a quick 50 line program to solve a problem, should I just dismiss that program as a script? Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Give up your modules!
- Original Message From: [EMAIL PROTECTED] I hate to let go, and would like to remain a consultant (!), but I'm willing to hand over my modules; listed below. Thanks in advance to anyone willing to take on the burden. That sounds great. I'm glad to hear you're willing to do this. Of course, you could always just offer co-maintainership via PAUSE if you don't want to give them up completely :) I know some authors have had a lot of success with similar announcements on Perlmonks or even use.perl. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Give up your modules!
- Original Message From: Jonathan Rockway [EMAIL PROTECTED] To: James E Keenan [EMAIL PROTECTED] Cc: module-authors@perl.org; Ovid [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 12:50:47 AM Subject: Re: Give up your modules! Is there software that needs to be written? I could write a small Catalyst application to handle this, if someone is willing to host it. I suspect this isn't what you were talking about, but we could also assign weights to various components: 1. The number of bug reports and their severity. 2. Number of days since last release. 3. The number of CPAN tester reports (total, separating test failures is useless since those are mostly a waste of time) 4. The number of other modules which have a dependency on the current module. Multiply each number by its weight and sum them. Skip if no bugs are in RT (or multiply the first result by the next 3?) Thus, a module with a severe bug but no tester reports and no other modules requiring it would probably not show up. A module with 3 severe bugs, hasn't been updated in 7 months, has over 50 CPAN tester reports and is widely used as a dependency is going to shoot near the top of the list. 3. (And this is the delicate part ...) A way to encourage authors/maintainers whose code needs transfer to a new maintainer to effect that. The scheme I mention above might help. It also might get a lynch mob showing up at my door. Nothing wrong with a good-old-fashion hostile fork now and again :) But hopefully we can avoid that. I'd almost be inclined to have takeovers than forks, but I suspect I'll be universally shouted down over that one. If module authors are unwilling to fix bugs in critical proojects and not allow comaintainers, the poor end-user is stuck. When working on large projects, it's usually far easier to get approval to upgrade a module than to change it (not to mention the fact that the work is easier, too). I completely realize that maintaining a lot of CPAN modules can be difficult at times. We have up times where we get a lot of stuff done and down times where we need to relax. That's OK. But not giving users a way out when they encounter problems just isn't fair. Why are we clinging to those modules if we're not going to fix them? More than once places I've worked at have vetoed modules because they do everything we want, just the way we want it, but the bugs kill us and the author is unresponsive. Then we have to find an alternative or make one. Cheers, Ovid
Re: Give up your modules!
- Original Message From: Gabor Szabo [EMAIL PROTECTED] I guess such thing should be part of CPANTS. ++ -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Give up your modules!
Hi all, No names, but if you happen to be sitting on a module which other people depend on and you're not going to fix bugs, give up the module, offer someone co-maintainership or figure out *something* which gives users a way out. I realize that not everyone has a pile of free time to constantly upgrade and maintain modules, but if it's something widely used and you don't have time for it, isn't the responsible thing to find a way to get those bug fixes out there? Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Indexing for AI-Prolog-0.735_01?
- Original Message From: Ken Williams [EMAIL PROTECTED] BTW, you might want to add a see also in the AI::Prolog docs for the SWI-Prolog wrapper? Probably a good idea. It's recommended in AI::Prolog::Article, but that's about it. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: Indexing for AI-Prolog-0.735_01?
- Original Message From: Joshua ben Jore [EMAIL PROTECTED] PAUSE says to send problems to modules@perl.org but perl.org's web page says that's a closed list?! So now this is two problems. One is why PAUSE isn't indexing AI-Prolog and the other is that the published contact doesn't accept messages from authors. Or doesn't *seem* to anyway. Maybe it's just me not understanding how things work (no big surprise there, eh?), but I've also noticed that http://search.cpan.org/dist/AI-Prolog/ points to your release but searching for AI::Prolog only shows mine (http://search.cpan.org/search?query=AI%3A%3APrologmode=all). By the way, thanks for working on this. I appreciate it. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
RFC: Class::CGI
Hi all,
A long time ago I toyed with the idea of treating HTML forms as object
collections.nnI've gone ahead and written an alpha which you can read
about at http://www.perlmonks.org/?node_id=541983
Note that one of my replies covers some changes which I have not
uploaded yet, but in a nutshell, you can do stuff like this:
use Class::CGI
handlers = {
customer = 'Class::CGI::Customer',
date = 'My::Date::Handler',
};
my $cgi = Class::CGI-new;
my $cust = $cgi-param('customer');
my $date = $cgi-param('date');
my $name = $cust-name; # look ma, objects!
my $year = $date-year;
The handlers are ridiculously easy to write and they encapsulate
everything they need to know for building those objects. In fact,
there may not even be a real date param, but just year, month and
date fields. Or maybe there is a date param and the handler can
handle either that or the aforementioned fields. No matter how you set
things up, your end user merely calls $cgi-param('date') and
everything is handled transparently, right down to the data validation
and untainting.
This makes it very easy to provide a handler to all of your scripts and
classes. Further, using handlers extensively means you're more likely
to use consistent parameter names throughout your site, making your
code more maintainable.
Of course, you can still call $cgi-raw_param('customer') to get the
actual value without driving it through the handler.
You can also set handlers on Class::CGI instances in case you're
working in a persistent environment and you don't want all of your code
to use the same handlers for the same parameters.
Comments, thoughts and suggestions are welcome.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: New Module Proposal - Math::Interval
Hi Brendan, I think Math::Interval is a fine name. If anyone is looking for a module which handles intervals, they'll find it immediately. The main question you seemed to have about this is: Should I create one module Math::Interval or a hierarchy such as: Math::Interval Math::Interval::Arithmetic Math::Interval::Trigonometric Math::Interval::Logarithmic That seems to be in relation to: This module would contain the basic definition and support functions for intervals. I think it should also include the basic arithmetic operations (+, -, *, /) but I have received the suggestion to break those out into a separate module (Math::Interval::Arithmetic). That would allow other people to add their own extensions. Not having seem your code, I'm at a loss to give you a clear answer, but I can give you a good rule of thumb: so long as you create a good, clear API which will not change (unless labeled alpha, experimental, etc.), don't worry about the module organization as much. Write the code you need and use it. As you use it more, you'll have a better understanding of how things should naturally be decomposed. You can do that yourself or, if enough others are interested, post it to the CPAN and ask for feedback. I'd also strongly recommend that you post this to Perlmonks. There are one or two mathematicians running around there. (Oh, and tell Wren I said hi :) Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC strict::can -- misunderstandings
--- Kurt Starsinic [EMAIL PROTECTED] wrote: Or, since it's overriding UNIVERSAL, UNIVERSAL::can::strict It's overridding UNIVERSAL::can (via inheritance). It's not replacing it. If you want to use this module for your module, you have the new can() method. Other modules are unaffected. Perhaps the docs are not clear in that respect. How about UNIVERSAL::should? The UNIVERSAL:: namespace is not appropriate as I'm not doing anything there. Still, I hate the name strict::can (I think I mentioned that before but it was buried at the bottom of an email). I do like should, though. Class::Should? Ugh. That doesn't quite fit either. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC strict::can
--- Kurt Starsinic [EMAIL PROTECTED] wrote:
similar to this solved a problem I had with Class::Trait
whereby I was exporting methods which should not have
been exported.
Do you mean calling methods which should not have been
called?
No. I did mean which should not have been exported, but a thorough
explanation of traits and what they do won't fit into this margin.
What I'm asking for, if you're interested in feedback,
is an example of a situation where youvre imported a
function into a class, from other code you've called
can() on said class before invoking a method call, it
did The Wrong Thing,
This is actually very easy to do in capability based systems. For
example, let's say I want the clone method from Clone.pm, but I want
to call it as a function:
package Foo;
use Clone 'clone';
sub new { bless {}, shift }
sub frobnicate {
my $self = shift;
my $args = clone([EMAIL PROTECTED]); # don't mess with their refs!
...
}
I've imported the clone function quite a few times but it's quite
reasonable for someone to do this:
my $foo = Foo-new;
# later
if ( $foo-can('clone') ) { # whoops
Yes, they can just call the clone() method directly and watch things
blow up but if they're testing an objects capabilities first, they get
a bit of sanity.
You *are* suggesting making this a pragma under the very
well-known strict namespace and putting it on CPAN, so I'm
expressing my personal concern that it may not be as generally
useful and safe as the nomenclature might suggest.
I agree that the name is ugly. I only used that after I saw Sean
Burke's strict::ModuleName.
Namespace suggestions are quite welcome.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
RFC strict::can
strict::can is a module which, if used, imports a can method into
your namespace. This version of can() will not report imported helper
functions or private methods. Full docs below.
Comments and suggestions welcome.
Cheers,
Ovid
--
NAME
strict::can - Make can() ignore private methods and imported
subroutines
VERSION
Version 0.01
SYNOPSIS
package Foo;
use strict::can;
use HTML::Entities qw(encode_entities); # imported into Foo::
sub new { bless {}, shift }
sub _private { 'some private function' }
# later
Foo-can('new'); # true
Foo-can('encode_entities'); # false (because it's an imported
function)
Foo-can('_private'); # false (because it's a private
function, even
#though we can still call
it)
EXPORT
This module exports a can() method into your namespace.
DESCRIPTION
This module gives your classes a can() method which overrides
(not
replaces) UNIVERSAL::can. In most respects it behaves like you
expect
it should, but does not report private methods (see below) or
imported
functions.
Imported functions
Frequently we import helper functions into our namespace.
Ordinarily
can() will return the code reference for these functions even
though
this is probably not what we want. strict::can will return false
for
any imported functions/methods. If you want to expose them, write
wrapper methods for them.
{
package Foo;
use strict::can;
use HTML::Entities qw/encode_entities/; # import into Foo::
...
sub encode {
my ($self, @args) = @_;
return encode_entities(@args);
}
}
# later
if (Foo-can('encode_entities')) {
# never gets to here
}
Private methods
Methods which begin with an underscore are, by convention,
considered
private and should not be relied on. Unfortunately, can()
succeeds
with those, too. strict::can will return false for private
methods
unless the class checking can() is a *subclass* of the class or
instance it is checking. This is because we're allowing a little
more
trust for subclasses as private methods are often protected
methods
which subclasses should be allowed to use.
{
package Foo;
use strict::can;
...
sub _private {
return 'Top Sekret!';
}
}
# later
{
package main;
if (Foo-can('_private')) {
# never gets to here
}
}
{
package Foo::Bar;
our @ISA = qw(Foo);
if (Foo-can('_private')) {
# success at last!
}
}
AUTHOR
Curtis Ovid Poe, [EMAIL PROTECTED]
BUGS
Please report any bugs or feature requests to
[EMAIL PROTECTED], or through the web interface at
http://rt.cpan.org/NoAuth/ReportBug.html?Queue=strict-can. I will
be
notified, and then you'll automatically be notified of progress on
your
bug as I make changes.
SEE ALSO
The B::svref_2object function.
COPYRIGHT LICENSE
Copyright 2005 Curtis Ovid Poe, all rights reserved.
This program is free software; you can redistribute it and/or
modify it
under the same terms as Perl itself.
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC strict::can
--- Kurt Starsinic [EMAIL PROTECTED] wrote:
package Foo;
use Exporter;
use strict::can;
if (Foo-can('import')); # BOOM
I can provide other examples from my own code, but I
think you get the point.
The current version on my hard drive allows for import.
The module is clever, but it's not clear to me that it's
practically useful. Could you provide a real-world example
where this
would help to prevent or detect a programming error?
Your world and my world can be considerably different. Using code very
similar to this solved a problem I had with Class::Trait whereby I was
exporting methods which should not have been exported. Also, if one is
routinely in the habit of checking class capabilities rather than class
types, this can be quite useful.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Module naming mailing list? Was: Re: New module: FLV file parsing
--- Austin Schutz [EMAIL PROTECTED] wrote: Ok, you and a few other vocal people have very strong opinions about this, which I don't begrudge you. Can we move the discussions to a different list? While I certainly agree that long discussions about how to name modules get tedious after a while, discussions of what modules do and what modules should be named are so intertwined that we'd be forced to bounce back and forth between the lists. The first thing that would happen on a module naming list would be someone asking well, what does your module do? That's often followed by there's already a module which does that or maybe it should do X instead. Then that conversation would legitimately jump back here and would eventually jump to the naming list ... over and over again. That would be even more tedious (hard to believe, I know). Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Another CPANTS/pod_coverage.t rant - FULL VERSION
--- Andy Lester [EMAIL PROTECTED] wrote: No. Module::Starter is a case where I'm using the package as evangelism. If it's for evangalism, could we have Build.PL do the right thing and have Module::Starter::Simple add the following line? create_makefile_pl = 'traditional', The reasons are detailed in http://perlmonks.org/index.pl?node_id=458282 Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Making RPMs out of CPAN Modules (namely XML::Feed) Automatically
--- Shlomi Fish [EMAIL PROTECTED] wrote: 2. Ovid - http://search.cpan.org/dist/Ovid/ - Slightly less updated to handle all the latest CPAN technologies (Module::*, ExtUtils::*, etc.). But does recursion. FYI: Just as POE has nothing to do with me (Curtis Poe), Ovid also has nothing to do with me. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC - Test::Stupid module
--- _brian_d_foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], A. Pagaltzis [EMAIL PROTECTED] wrote: Using a tool from CPAN is not conceptually different from what youâre doing, but a good way for developers who havenât developed specific needs and wants (yet) to get a headstart on doing things properly. It is completely different. A tool from CPAN is somebody else's idea of what your module distro should look like. Mine, not being a module starter tool, is your own idea. It doesn't know anything about modules other than what you tell it. I have to agree with this. Long before module-starter came along, I wrote a bash script which, using Template Toolkit, would build the shell of a distribution for me. It also managed source control, various utilities that I enjoy, and set things up just the way I like 'em for my environment. It would be nearly useless for anyone else. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
--- A. Pagaltzis [EMAIL PROTECTED] wrote: Even if Iâve not convinced you, I know this will be what Iâll be doing henceforth. :-) OK, I'm convinced. I played around with it for a bit it's close to what I want. The reason it didn't seem like an option at first is the documentation does not make it clear I can lock a non-existing key and later assign a value. I suppose the docs *could* be read that way, but if the docs explicitly said that the restricted keys may contain keys not already present in the hash, I'd have understood. Thanks! Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Hash::HasKeys
--- Ken Williams [EMAIL PROTECTED] wrote: I wasn't asking about P::V's disabled mode (I never use that either), I was asking if you actually know its performance hit is too much in its enabled mode. Have you benchmarked? No. I was trusting my boss's reasoning for not wanting to use P::V and when I saw all of that documentation when I just wanted to check the darned keys, I thought I don't need all of that. Of course, I also whine quite a bit about Perl's awful argument handling, so I suppose I should buck up and take a look at the module. I'm just being silly not doing so. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
