module-authors@perl.org wrote:
Perhaps it should be named
Params::Validate::Derivable
or something along those lines.
I agree, but given that being derivable is something really important
for being able to be called OOP, why not:
Params::Validate::OO - Derivable parameter validation
--
S
"Ken Williams" <[EMAIL PROTECTED]> writes:
> On Jan 5, 2005, at 3:29 PM, Graciliano M. P. wrote:
>
>> You should compress the data and than append it with __DATA__ or as
>> a string
>> saved with Base64 to avoid binary errors.
>
> I think not - then you'd have to decompress it every time you used
On Jan 5, 2005, at 8:24 PM, Rhet Turnbull wrote:
module. Just gzip it and put it on whatever distribution site you
choose (which may or may not be CPAN) and then users will decompress
before installation.
Why not just keep the file gzipped and use IO::Zlib to read it at run
time? The speed differ
> module. Just gzip it and put it on whatever distribution site you
> choose (which may or may not be CPAN) and then users will decompress
> before installation.
Why not just keep the file gzipped and use IO::Zlib to read it at run
time? The speed difference will probably not even be noticeable.
Dear Daisuke,
I think your new module is a great addition to Params::Validate but I
think the naming should imply it's relation to Params::Validate.
Perhaps it should be named
Params::Validate::Derivable
or something along those lines.
If nothing else, the one line description in the
On Jan 5, 2005, at 3:29 PM, Graciliano M. P. wrote:
You should compress the data and than append it with __DATA__ or as a
string
saved with Base64 to avoid binary errors.
I think not - then you'd have to decompress it every time you used the
module. Just gzip it and put it on whatever distributi
On Jan 5, 2005, at 4:27 PM, David Landgren wrote:
People,
I happened to look at my module through search.cpan.org and noticed
that the License field says "unknown". The pod states that the module
is released under the same terms as Perl itself. Am I correct in
assuming that if I add
license: pe
On Jan 4, 2005, at 6:06 PM, Ovid wrote:
--- Eric Wilhelm <[EMAIL PROTECTED]> wrote:
Me too, except for how it reads in the 'use' statement.
use aka 'Really::Long::Module::Name';
Yeah, that bugs me too. Still, aka.pm is the name I lean toward.
It any case, it seems that
'alias.pm' might get confu
People,
I happened to look at my module through search.cpan.org and noticed that
the License field says "unknown". The pod states that the module is
released under the same terms as Perl itself. Am I correct in assuming
that if I add
license: perl
to the META.yml file, this will correct the sit
You should compress the data and than append it with __DATA__ or as a string
saved with Base64 to avoid binary errors.
Here's a simple sample:
use Compress::Zlib qw(compress uncompress) ;
use MIME::Base64 qw(encode_base64 decode_base64) ;
my $uncompressed = 'some sample data' ;
my $base
In article <[EMAIL PROTECTED]>,
Dana Hudes <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Jan 2005, Scott W Gifford wrote:
>
> > A private emailer wrote:
> >
> > [...]
> >
> > > Even better isn't all this on a USPS server? Whatever tool you use
> > > to grab their server database, include it and do tha
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <[EMAIL PROTECTED]>, Scott W
Gifford <[EMAIL PROTECTED]> wrote:
> I'm working with T.J. Mather on updating Geo::PostalCode. One of the
> things we're looking at is how to manage
On Wed, Jan 05, 2005 at 02:19:31PM +0100, Dariush Pietrzak wrote:
> On Wed, 5 Jan 2005, Austin Schutz wrote:
> > Why not just add the functionality to Net::FTP? Or you could
> > subclass Net::FTP and call it something clever like Net::FTP::TLS.
> Because Net::FTP is written in a way that makes
Title: RE: Module Name: Net::Lite::FTP
On 05 January 2005 18:16 Ovid wrote:
> > I'd much rather see you work with the existing Net::FTP
> > and enhance it either by patching or by subclassing.
>
> If I understood the original author correctly, he could not patch
> Net::FTP because those worki
--- Dana Hudes <[EMAIL PROTECTED]> wrote:
> Reinventing the wheel is a bad idea.
Reinventing the wheel is *often* a bad idea. Never say never :)
> I'd much rather see you work with the existing Net::FTP
> and enhance it either by patching or by subclassing.
If I understood the original author c
Reinventing the wheel is a bad idea.
FTP looks simple but you have to consider all manner of issues
such as buffer overflows and so forth.
I'd much rather see you work with the existing Net::FTP
and enhance it either by patching or by subclassing.
Net::FTP is widely used therefore bugs and other o
David Landgren wrote:
Dariush Pietrzak wrote:
On Wed, 5 Jan 2005, Austin Schutz wrote:
Why not just add the functionality to Net::FTP? Or you could
subclass Net::FTP and call it something clever like
Net::FTP::TLS.
...
I'd still favour going with the name Net::FTP::TLS, even if it isn't
subclass
Dariush Pietrzak wrote:
On Wed, 5 Jan 2005, Austin Schutz wrote:
Why not just add the functionality to Net::FTP? Or you could
subclass Net::FTP and call it something clever like Net::FTP::TLS.
Because Net::FTP is written in a way that makes it extremely hard to make
needed modifications.
On Wed, 5 Jan 2005, Austin Schutz wrote:
> Why not just add the functionality to Net::FTP? Or you could
> subclass Net::FTP and call it something clever like Net::FTP::TLS.
Because Net::FTP is written in a way that makes it extremely hard to make
needed modifications.
It is a very well-tho
Title: RE: Module naming advice
> Which is my problem with 'alias.' Case-insensitive systems will
> happily load a module with incorrect case (after loading,
> though, using the name with incorrect case will cause problems).
> Which module would get loaded?
Assuming they are both instal
On Wed, Jan 05, 2005 at 11:59:22AM +0100, Dariush Pietrzak wrote:
> Hi,
> I'm going to release on CPAN simple FTP client implementation.
> This module is very simple, but provides access to TLS-enabled servers, and
> is going to be a testbed for few relatively new extensions to ftp, like
> statefu
Hi,
I'm going to release on CPAN simple FTP client implementation.
This module is very simple, but provides access to TLS-enabled servers, and
is going to be a testbed for few relatively new extensions to ftp, like
statefull-firewall-piercing-while-encrypting-both-data-and-control-channel;).
Int
On Tue, 4 Jan 2005, Scott W Gifford wrote:
> The advantages of having the data on CPAN is that the entire module is
> self-sufficient and widely mirrored. It makes it much easier to
> install, and if you have a CPAN distribution on CD or in a local
> mirror, you have everything you need. The dis
23 matches
Mail list logo
