Re: Arguments checker module
Do you mean Parse::Method::Signatures ? On Tue, May 5, 2009 at 10:54 PM, breno oainikus...@gmail.com wrote: On Wed, May 6, 2009 at 12:04 AM, Bill Ward b...@wards.net wrote: Params::Validate has the right features, but I really don't like the verbosity of its configuration. I was hoping for something more like the Perl prototyping or Getopt::Long syntax. Maybe I'll write a wrapper around Params::Validate? Have you looked at Method::Signatures? -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: Arguments checker module
On Wed, May 6, 2009 at 2:59 AM, Bill Ward b...@wards.net wrote: Do you mean Parse::Method::Signatures ? No, I mean http://search.cpan.org/perldoc?Method::Signatures http://www.slideshare.net/schwern/methodsignatures-presentation I haven't looked at it much, but it seems to fill most of your needs (not tied to Moose, usable from within methods with a prototype-like interface). Although it doesn't seem to perform much of a validation (except for types and traits, I guess), you probably could extend it with callbacks and regexp the same way Params::Validate does (although, since you complained about its verbosity, it appears to not be the case). Cheers,
Re: Arguments checker module
On Tue, May 5, 2009 at 11:48 PM, breno oainikus...@gmail.com wrote: On Wed, May 6, 2009 at 2:59 AM, Bill Ward b...@wards.net wrote: Do you mean Parse::Method::Signatures ? No, I mean http://search.cpan.org/perldoc?Method::Signatures http://www.slideshare.net/schwern/methodsignatures-presentation I haven't looked at it much, but it seems to fill most of your needs (not tied to Moose, usable from within methods with a prototype-like interface). Although it doesn't seem to perform much of a validation (except for types and traits, I guess), you probably could extend it with callbacks and regexp the same way Params::Validate does (although, since you complained about its verbosity, it appears to not be the case). It has two deal-breakers for me: 1. Same problem as Moose - it changes the language too much for my taste. I don't see what all the fuss is about declaring $self. 2. Not robust enough - big alpha software warnings are a huge turn-off to me.
Re: Arguments checker module
You seem to hate everything. I am confused as to why people even waste their time trying to help you. * On Wed, May 06 2009, Bill Ward wrote: 1. Same problem as Moose - it changes the language too much for my taste. I don't see what all the fuss is about declaring $self. Most people want to write code that implements the logic of their application, not work-arounds for missing language features. You write that once, and then use it everywhere. Reuse, they call it. Less noise == code that's easier to read and understand. That's what the fuss is about. 2. Not robust enough - big alpha software warnings are a huge turn-off to me. I think it's more like, anything I didn't write is a huge turn-off to me. Admitting that is the first step ;) But anyway, I would also avoid Method::Signatures -- it was just some stuff from the Devel::Declare test suite that Schwern++ decided to CPAN. MooseX::Method::Signatures (and MooseX::Declare) is the production-ready version. (And yes, I do use MX::Declare in several production applications. It has not caused me any problems at all, other than perhaps a bit of extra wear on the tab key.) Anyway, embrace modules. They are the reason to use Perl. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Arguments checker module
On Wed, May 6, 2009 at 6:50 AM, Jonathan Rockway j...@jrock.us wrote: You seem to hate everything. I am confused as to why people even waste their time trying to help you. [snip] Anyway, embrace modules. They are the reason to use Perl. I think Bill gets Perl. (c.f. http://www.bayview.com/training/instructors.shtml) Jonathan, I hate to personalize things, but that kind of response is an example of what people mean when they talk about the Perl community being unfriendly. Moreover, Bill said he liked Params::Validate, just that it was wordy for him. It's not the first time someone in the Perl community thought something was wordy and wrapped it, given the number of ::Simple modules on CPAN. (362 distributions with Simple according to search.cpan.org) I don't think he deserves public scorn in response to a reasonable question and reasonable objections to suggestions. -- David
Comparing floating point numbers
On Tue, May 05, 2009 at 11:58:47AM -0700, Jonathan Leto wrote: [how to compare floating point numbers in tests] Check that it's in an acceptable range. I heartily agree with this. Math::GSL has thousands of tests like this, which is why Math::GSL::Test has a number of easy-to-use functions to do this. I very much recommend that you look at is_similar() in Math::GSL::Test, it has implemented at least a few wheels that you are destined to want: is_similar($x,$y;$eps,$similarity_function) is_similar($x,$y); is_similar($x, $y, 1e-7); I wonder if this is something that could be broken out of Math-GSL and put into Test::More - or at least released seperately so that people can use it without Math::GSL's dependencies. Of those, ExtUtils::PkgConfig is a bit of a showstopper for lots of people. Added TSCH to the CC list. -- David Cantrell | Nth greatest programmer in the world If I could read only one thing it would be the future, in the entrails of the bastard denying me access to anything else.
Re: Puzzling error from cpan testers
On Tue, May 05, 2009 at 03:05:49PM -0400, David Golden wrote: Yikes. You must have missed Test::Number::Delta ... Harr! That'll teach me to read the whole thread before replying! -- David Cantrell | Enforcer, South London Linguistic Massive Irregular English: you have anecdotes; they have data; I have proof
Re: Arguments checker module
On Wed, May 06, 2009 at 07:10:49AM -0400, David Golden wrote: I don't think he deserves public scorn in response to a reasonable question and reasonable objections to suggestions. I agree about the public scorn, but I disagree that Perl 5's OO is fine is reasonable. It's horrible; we just all forget that because we're used to it and know it inside and out. hdp.
Re: Arguments checker module
On Wed, May 6, 2009 at 6:38 AM, Hans Dieter Pearcey hdp.perl.module-auth...@weftsoar.net wrote: On Wed, May 06, 2009 at 07:10:49AM -0400, David Golden wrote: I don't think he deserves public scorn in response to a reasonable question and reasonable objections to suggestions. I agree about the public scorn, but I disagree that Perl 5's OO is fine is reasonable. It's horrible; we just all forget that because we're used to it and know it inside and out. Thanks guys for sticking up for me. I am just old-fashioned, I guess; for better or for worse, I'm not interested in changing/fixing Perl itself, just in finding writing reusable code that meets my needs without adding stuff that doesn't.
Re: Arguments checker module
Howdy, Thanks guys for sticking up for me. I am just old-fashioned, I guess; for better or for worse, I'm not interested in changing/fixing Perl itself, just in finding writing reusable code that meets my needs without adding stuff that doesn't. Wow, I was taken aback when I read not interested in changing/fixing Perl itself. Ever heard of technical debt? You can feel it every time you type my ($self) = @_. Also, Perl 5 doesn't have OO, it has blessed scalars. Just sayin' ;). If you want to maximize your code reuse, I suggest drinking the Moose Koolaid and learning about roles [1]. Chromatic has a pretty nice description [2] and hdp gave a nice description of them at a recent PDX.pm [3]. Cheers, [1] http://search.cpan.org/dist/Moose/lib/Moose/Role.pm [2] http://www.modernperlbooks.com/mt/2009/04/the-why-of-perl-roles.html [3] http://www.weftsoar.net/~hdp/talk/meta-moose/slides/start.html -- Jonathan Leto jonat...@leto.net http://leto.net
Re: Arguments checker module
On Wed, May 6, 2009 at 10:42 AM, Jonathan Leto jal...@gmail.com wrote: Howdy, Thanks guys for sticking up for me. I am just old-fashioned, I guess; for better or for worse, I'm not interested in changing/fixing Perl itself, just in finding writing reusable code that meets my needs without adding stuff that doesn't. Wow, I was taken aback when I read not interested in changing/fixing Perl itself. Ever heard of technical debt? You can feel it every time you type my ($self) = @_. Also, Perl 5 doesn't have OO, it has blessed scalars. Just sayin' ;). If you want to maximize your code reuse, I suggest drinking the Moose Koolaid and learning about roles [1]. Chromatic has a pretty nice description [2] and hdp gave a nice description of them at a recent PDX.pm [3]. There are a couple of big problems with adopting Moose or one of the similar redesigns of Perl OO. 1. Not every module you're using will be Moose-based, so if you're working on one of those, you'll need to remember to switch back and forth. It's bad enough having both (Perl's approximation of) OO and procedural calls. 2. If we bring someone new onto the team we'd have to train them not just in Perl, but in Moose as well. There are tons of books and online resources for Perl, but only Moose's own documentation for that. All the examples, code snippets, books, and howtos that people might want to use would have to be adapted to fit into a Moose framework. 3. If I am going to change languages, I'd rather switch to Ruby or Python.
Re: Arguments checker module
On Wed, May 06, 2009 at 11:27:05AM -0700, Bill Ward wrote: 1. Not every module you're using will be Moose-based, so if you're working on one of those, you'll need to remember to switch back and forth. It's bad enough having both (Perl's approximation of) OO and procedural calls. If you're *using* a module, why do you care what its implementation is? It's not like Moose classes name all their methods 'call_moose_method_foo', or have constructors named 'NEW', or something. I regularly work on codebases that use both Moose and non-Moose APIs, and I don't see any 'switching back and forth' related to that. (Sometimes the non-Moose classes have dumb API design, and I have to remember that this particular method has bizarre error condition signalling, but that's orthogonal to Moose or not.) It's certainly nothing like method calls vs. function calls. Have I misunderstood you? 3. If I am going to change languages, I'd rather switch to Ruby or Python. If Moose somehow precluded your use of non-Moose Perl code, this would be relevant. hdp.
Re: Arguments checker module
Howdy, There are a couple of big problems with adopting Moose or one of the similar redesigns of Perl OO. You mean implementing OO in Perl, but I get it. 1. Not every module you're using will be Moose-based, so if you're working on one of those, you'll need to remember to switch back and forth. It's bad enough having both (Perl's approximation of) OO and procedural calls. From what I know (hdp would know much better), Moose can interact just fine with non-Moose modules. For instance, check out MooseX::NonMoose [1]. So, this is false. 2. If we bring someone new onto the team we'd have to train them not just in Perl, but in Moose as well. There are tons of books and online resources for Perl, but only Moose's own documentation for that. All the examples, code snippets, books, and howtos that people might want to use would have to be adapted to fit into a Moose framework. Huh? Moose is 50 times simpler to learn that Perl 5's hacktastic OO implementation. And they would have to write about 50 times less code. And hopefully you are hiring people that can learn new things. All you have to say is use Moose's features for creating/maintaining your objects, everything else is the same. 3. If I am going to change languages, I'd rather switch to Ruby or Python. Moose is still Perl 5! And it will help you transition to Perl 6, if you don't decide to switch to Ruby or Python. Cheers, [1] http://search.cpan.org/~doy/MooseX-NonMoose-0.02/lib/MooseX/NonMoose.pm -- Jonathan Leto jonat...@leto.net http://leto.net
Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
On Tue, 5 May 2009 19:09:30 -0700 Bill Ward b...@wards.net wrote: The way I've interpreted that in my own auto-build scripting is that if Build.PL exists, the module author is probably a Module::Build user who is only providing a Makefile.PL grudgingly for the sake of those who haven't installed Module::Build, and thus I figure that if there's any difference between the two .PL files, probably Build.PL is the one the author is more invested in. That's the logic I work to, yes. All my Makefile.PLs are built from the original Build.PLs. On Tue, May 5, 2009 at 7:06 PM, Jonathan Yu jonathan.i...@gmail.com wrote: The real question at hand here is: for modules that provide both a Makefile.PL and Build.PL, which should be preferred? More than that, from the perspective of CPAN authors, is it even useful to provide both? Now that Module::Build is a core module, maybe only a Build.PL should be included. But only core in 5.10. I've decided semi-officially that I don't care about 5.6 any more, in that I'll happily use Scalar::Util::weaken(), or other 5.8-and-above things, unless someone can demonstrate me a simple workaround for them that would work on 5.6. I don't yet apply the same for 5.10, as 5.8 is still the default in lots of places. Perhaps in a year or two I might rethink that, but for now I have to keep 5.8 in mind. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Arguments checker module
On Wed, May 6, 2009 at 3:54 PM, Paul LeoNerd Evans leon...@leonerd.org.ukwrote: On Wed, 6 May 2009 11:27:05 -0700 Bill Ward b...@wards.net wrote: (Perl's approximation of) OO I've often seen this one bandied about, and I can't say I agree with it. Neither do I, but I threw the parenthetical in to placate the person to whom I was replying. Perl's the only language I've done OO programming in for about 16 years so I'm quite happy with it the way it is.
