Re: Module Proposal: Log::Any
> So I guess what I'm saying is that the final thing that would stop me from > using Log::Any "everywhere" (meaning also in performance-critical code) is > the overhead for the common (production) case of logging being entirely > disabled. How about providing all three methods of checking as part of the > API? > > $log->debug(...) if $log->is_debug(); # method > $log->debug(...) if Log::Any::is_debug(); # sub > $log->debug(...) if $Log::Any::Is_Debug; # var Good point. The last two need to be tweaked so that we can assign different logging levels and/or destinations to different loggers - e.g. to turn on just Rose::DB debug logging without a flood from other modules. (See log4perl). How about this: use Log::Abstract qw($log $log_is_debug); $log->debug(...) if $log_is_debug; which translates to something like use Log::Abstract; my $log = Log::Abstract->get_logger (category => __PACKAGE__, is_debug_flag => \my $log_is_debug); $log->debug(...) if $log_is_debug; Now $log_is_debug, like $log, is class/category specific. Note that with either syntax, Log::Abstract is able to keep track of all the $log_is_debug variables and update them at runtime when something happens in the log framework to change log levels (e.g. log4perl reloading configuration). Assuming log level changes happen infrequently, this should yield good performance even when logging is turned on.
Re: advice on where to put my perl modules
After listening to what people have said on and off the list, I think will create a top-level namespace. I have seen this done before, and it seems to be the advice I am getting.
advice on where to put my perl modules
I am seeking advice on where to put my Perl modules called MyLibrary. MyLibrary is a set of object-oriented Perl modules for libraries (think books and such) allowing librarians to create digital libraries. The modules are for a rather specific purpose in that they do I/O against a specifically shaped relational database, but not necessarily a specific relational database system. I realize CPAN is primarily intended for modules that may be of a more generic nature, and I'm wondering how MyLibrary might fit into CPAN and where I would put it if it does. I friend of mine said maybe some sort of top-level location, but that sounds drastic. What are your suggestions? -- Eric Lease Morgan University Libraries of Notre Dame [EMAIL PROTECTED]
Module name advice
Hi, I am writing a Perl driver for Selenium, a website testing tool [1], and I need to choose a proper name for the module. Having discarded a top-level namespace, I am now inclined to use WWW::Selenium for the Selenium driver and Test::Selenium for the TAP-emitting module to be used in test scripts. Does anybody have suggestions? Thanks! Mattia [1] http://selenium.thoughtworks.com/index.html
Re: Author's namespace
From: A. Pagaltzis [EMAIL PROTECTED] > I wasn't saying the code was trash - but a carelessly chosen name > and no documentation do make it clutter.. I agree it's clutter that's why I'd like it not to be included when people search. The name is chosen for my convenience and mine only. As Mark mentioned in his mail, it's more of a personal style thing and as Mark mentioned it could be a bad idea as people start building repositories of their own secret modules rather than making the effort to release them properly. > How about putting the module under the *same* name in all your > distributions that use it? This doesn't avoid duplication on > CPAN, granted - but does avoid it on the user end. Instead of > calling it Test::Deep:MM, Foo::Bar::MM, Baz::Quux::MM etc > depending on the distro, just stick it in all distros under the > same name, maybe something like Class::MyMethodMk. But that will clash with Blah-Blah's Class::MyMethodMk. Anyway, I'm not too stressed about the whole thing. I'm more interested in a related Proposed:: namespace which came up in passing. As in Proposed::FDALY::Hey::ModuleAuthors::IsThis::A::GoodName::For::ThisModule F mail2web - Check your email from the web at http://mail2web.com/ .
Re: Author's namespace
Original Message: - From: Struan Donald [EMAIL PROTECTED] > And if you're including the code in several CPAN modules then > shouldn't the code be up to standard for general use? Just because you > can't see anyone wanting to use it doesn't mean it shouldn't be > documented. The code is fine, it's quite simple and doesn't really need docs, however I don't really want anyone else using it because then it becomes a responsibilty. There are plenty of similar modules contained within existing distributions. They are not polished, have no pod etc. They are only to be used from within the distribution itself and only need to be understood by people changing the distribution in question. I don't think this bothers people too much. My module is like these, it has previously shipped inside another distro, undocumented, unexposed. I want to use it with several other modules but I don't want to cut and paste. As it happens, it looks like the original Class::MethodMaker has an undocumented way to do what I want, so for this module it may not be an issue but everyone has their own file slurping routine and various other bits and bobs that they do their own way, rather than copying them into lots of modules, a personal namespace of utility stuff could be useful. Also somewhere to put things which are under review is also useful and seems to have been lost in the methodmaker discussion. > Anyone using one of those CPAN modules shouldn't have to > ferret around in source code to realise what your convience methods > are there for. Ideally, anyone using one of my CPAN modules shouldn't have to ferret around in any of my code documented or not but if they are then chances are that documenting these particular bits would make no difference, F mail2web - Check your email from the web at http://mail2web.com/ .
Re: Class::FakeAttributes -- Opinions Wanted
From: A. Pagaltzis [EMAIL PROTECTED]
> And then there's accessor/mutator generation.. ie what
> ::MethodMaker does. Which there seems to be no easy way to do
> (with lexicals) using inside out objects..
Wouldn't this do what you want (roughly, it may not actually compile...)
use Scalar::Util qw(refaddr);
{
my %attribs;
sub make_attr {
my $class = shift;
my $attr = shift;
my $full = "${class}::${attr}";
my $sub = sub {
my $s=shift;
if (@_) {
$attribs{$full}->{refaddr($s)}=shift;
return $s;
} else {
return $attribs{$full}->{refaddr($s)};
}
}
*{$full} = $sub;
}
}
obviously you'd add an import method to make it nice to use too,
F
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Class::FakeAttributes -- Opinions Wanted
How about Class::SafeAttributes. Because you can safely add atrributes. Compared to FakeAttributes, it's more descriptive of the purpose rather than the implementation, F Original Message: - From: Smylers [EMAIL PROTECTED] Exactly. They're 'fake' in that they aren't considered part of the object by Perl (and won't be freed by Perl automatically on destruction). mail2web - Check your email from the web at http://mail2web.com/ .
Re: module to access w3c validator
There are 2 or 3 things that need to be in the name, "Validator", that's what it is, "HTML" because that's what works on and possibly "W3C" because that's where the engine comes from, so I'd suggest HTML::Validator::W3C Just from a searching point of view, this is a much easier module name to find. I think Detailed is unnecessary since there isn't already a module out there that gives an undetailed set of results, F From: Struan Donald [EMAIL PROTECTED] >So, does WWW::Validator::W3CMarkup::Detailed seem like a good name for > this? mail2web - Check your email from the web at http://mail2web.com/ .
RE: module to access w3c validator
From: Christopher Hicks [EMAIL PROTECTED] > All of this presumes that the effort required to install the validator > locally is near zero. I just went out to look and it honestly doesn't > look too hard to make work, but neither did their css validator which I > gave up on getting installed locally because of fighting with all of the > Java garbage. YMMV. I have no idea but yes it looked easy and they claim it works on a wide variety of systems (including HP-UX). > Even if the HTML validator is easy to get going that doesn't mean that it > still isn't often easier to not install it. Honestly I could see using > this module when working on things at remote sites. It'd certainly be > easier to get the original poster's module installed than trying to figure > out whether OpenSP compiles on HP-UX or wait a month for my client to > approve adding software to their production linux system. When working > with a few TLA US goverment agencies the "mean time from begging to > getting actual software installed" is about ten months. Fair points except in this case you wouldn't be doing your clients any favours by making their production servers depend on a webservice that has no specified interface and no promises about availability. F mail2web - Check your email from the web at http://mail2web.com/ .
RE: module to access w3c validator
I don't really understand your answer, so I'll rephrase my question. If you can get the source then why would you want to do anything using SOAP? If the source has a free enough license you could turn it into a module and that's that, if not then just run it locally as a command and capture the output. Either of these would be much more reliable than remotely calling the w3c's scripts, you wouldn't need to be connected to use it and you won't be pounding on the w3c's servers, F Original Message: ----- From: Sherzod Ruzmetov [EMAIL PROTECTED] : If you can get the source then why bother putting it on a : server, wrapping it : in SOAP and calling it remotely? For the same reason why one would want to write a library to access W3C. mail2web - Check your email from the web at http://mail2web.com/ .
