On 11/06/2022 09:21, Neil Bowers wrote:
I’d go with WebService::PACER – WebService is *one* of the standard
namespaces on CPAN for this sort of module :-)
You could slip a USCourt in the middle, but I don’t think that’s
necessary – better to keep things simple.
It's not *necessary* but it i
I think if PACER is unambiguous (there's no other Web service named PACER)
then further qualification shouldn't be needed.
If PACER is a single standard that could be used for multiple services
other than the US courts (other countries were to implement the same
service with the same api) then qua
Is it specific to `UsCourt`? Could there be later a `MexicoCourt`?
On Sat, Jun 11, 2022, 10:22 Neil Bowers wrote:
> Hi Brian,
>
> I’d go with WebService::PACER – WebService is *one* of the standard
> namespaces on CPAN for this sort of module :-)
>
> You could slip a USCourt in the middle, but I
Hi Brian,
I’d go with WebService::PACER – WebService is *one* of the standard namespaces
on CPAN for this sort of module :-)
You could slip a USCourt in the middle, but I don’t think that’s necessary –
better to keep things simple.
Cheers,
Neil
On 6/9/22 21:02, Brian Erickson wrote:
I am developing a module for interacting with the United States PACER
(Public Access to Court Electronic Records) API. PACER is a US government
service that provides access to over one billion documents relating to
cases that were, or are being, tried befor
Thanks for all the suggestions! Given that the Perl module will, for now,
be more than just a web client (a portion of it will need to gather data by
parsing log files) I think I will go with App::Spoor - with the intent to
break off the part that has the webservice functionality into
Webservice::S
> On Jan 23, 2019, at 9:16 AM, Rory McKinley wrote:
>
> I am developing a hosted application called Spoor. I would like to build a
> Perl client module for this application that will (amongst other things)
> interact with the Spoor Api.
>
> My current inclination is to call the module Spoor::
There's APP:: - e.g. APP::Spoor::API & APP::Spoor::Client
On 23-Jan-19 10:16, Rory McKinley wrote:
> Hello
>
> I am developing a hosted application called Spoor. I would like to
> build a Perl client module for this application that will (amongst
> other things) interact with the Spoor Api.
>
>
Hi Timothy,
I just wanted to point out that there is some prior work in the realm of a
thing or two you mentioned in other modules:
Shell quoting:
As you mentioned, it's a big deal. Haarg has done quite a bit of work to
make this as complete as possible:
https://metacpan.org/pod/Win32::ShellQuote
On Thu, May 4, 2017 at 12:53 PM, Reini Urban wrote:
> Thinking about it, I like the name Net::FTP::Path::Iter best
>
> Reini Urban
> rur...@cpan.org
>
That sounds good to me as well. Thanks!
Neither wise nor a sage, but:
Is there a more general term than "Stereo", which implies 2: left and right?
What about other composite views that make an image appear to have
depth/perspective?
E.g. Hologram (Holo?) Is there a term that covers the space of all
composite views and/or related imag
Thinking about it, I like the name Net::FTP::Path::Iter best
Reini Urban
rur...@cpan.org
Correction, it subclasses Path::Iterator:Rule, which makes the names even
longer!
On Thu, May 4, 2017 at 10:07 AM, Diab Jerius
wrote:
> Howdy,
>
> I've developed a module which subclasses Path::Iter::Rule and uses
> Net::FTP to scan FTP sites [1]. I'm stuck on naming it.
>
> * Net::FTP::Rule (
Which would give you something like
Image::TriD::StereoPairs::MPO
I'm liking 'StereoPairs'. Unless there are strenuous objections,
I plan to go with...
Image::3D::StereoPair::MPO
Now all I have to do is write the software. :-)
Thanks to all for the feedback.
...BC
--
---
>
> Some would consider the following to be even more general and
> thus better:
>
>Image::3D::Pairs::MPO
>Image::3D::Pairs::JPS
>Image::3D::Pairs::JPG
>
>Image::3D::Lenticular
>Image::3D::VR
>Image::3D::Holo
>Image::3D::DepthMap
>
> But wouldn't this break the rule for
I'm sure you'll find a suitable compromise. My concern is the future -
ensuring that the next format and/or packaging of multiple images has a
place to fit. These things tend to evolve (complete with survivors and
dead-ends.)
But Image::3D:: isn't the only way to express three-dimensional...
th
Is there a more general term than "Stereo", which implies 2: left
and right?
Well as it would apply to stereographic imaging, that would be
"binocular", which is definitely two and only two. But there is
a very strong association of that term with the paired telescopes
commonly called binocular
On 05/03/2017 04:12 AM, Smylers wrote:
BC writes:
I'd like some feedback and advice for naming some modules I am
contemplating.
Image::Stereo::MPO
Image::Stereo::JPS
Image::Stereo::JPG
Sounds good to me — you've clearly considered this carefully, and your
explanations make sense.
S
Neither wise nor a sage, but:
Is there a more general term than "Stereo", which implies 2: left and right?
What about other composite views that make an image appear to have
depth/perspective?
E.g. Hologram (Holo?) Is there a term that covers the space of all
composite views and/or related imag
BC writes:
> I'd like some feedback and advice for naming some modules I am
> contemplating.
>
>Image::Stereo::MPO
>Image::Stereo::JPS
>Image::Stereo::JPG
Sounds good to me — you've clearly considered this carefully, and your
explanations make sense.
Smylers
--
http://twitter.com/S
Please be precise with the terminology. Do not use the package
separator when you mean the filesystem path separator. This is not a
1:1 mapping, so it matters.
> So if I wanted to add Math::Simple.pm, How would it show up
> and/or how would they be differentiated?
It would show up as unauthorise
Joshua,
> 2. It sounds like given the single function and it's relative uniqueness,
> there's no problem exporting it by default other than not being able to change
> it later. For the sake of forward compatibility, I'll probably just put it in
> @EXPORT_OK and require its explicit import.
Beari
Thank you for your replies - here's a bit more info:
1. This is not something that only runs on Win32; in fact, I doubt it will run
on Win32, as this uses the WMI code from the Samba project to support WMI on
non-Win32 platforms. WMI is Windows Management Instrumentation (or something
like tha
Hi Josh,
# from Joshua Megerman on Friday 14 September 2012:
>My initial inclination was to just call the
>module WMIClient, but I'm starting to think that WMI::Client or some
>other name would be better. The only 2 modules I currently see on
>CPAN that provide similar functionality are DBD::WMI
Joshua Megerman writes:
> I'm a new member of PAUSE, looking to upload my first module.
Hi Josh. Thanks for sharing with the Perl community.
> 1. I have developed a module that provides an XS interface to the WMI
> library (libasync_wmi_lib.so) that is generated by building the Zenoss WMI
> soft
Mail::Postfixadmin seems fine to me
On Tue, Dec 13, 2011 at 5:06 AM, Avi Greenbury wrote:
> Hi,
>
> I've been working on a module which basically makes it easy to write
> command-line tools for interacting with a postfixadmin[0] installation,
> that is a Postfix/Dovecot mail server with virtual
Hi Avi,
* Avi Greenbury [2011-12-13 14:10]:
> To me, this obviously belongs somewhere in the Mail namespace, but I'm
> not really sure where it should go in that. I'm tempted to rename it
> to Mail::Postfixadmin, but I don't want to give the impression that
> it's somehow endorsed by that project
Have you talked to the maintainer of Carp about this? It might be best to
just suggest it as a new feature in Carp itself.
Otherwise, Carp::Whence or something might seem reasonable to me.
On Sat, Mar 5, 2011 at 4:11 AM, Paul LeoNerd Evans
wrote:
> (To copypaste
> http://leonerds-code.blogspot.
Hi all,
It occurs to me that the uses for this could extend outside testing.
Looking at CPAN, the root namespace 'Include' already exists, so
Include::DontRun would be a viable name, and seems pretty descriptive
to me.
Anyone got any objections?
I've handled the __DATA__ and __END__ cases now.
When developing code to include
One might think it intolerably rude
To use words ungrammatical
As a method pragmatical
To avoid compilation being screwed
:-P
On 8 October 2010 00:13, Paul Johnson wrote:
> On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote:
>
>> Test::Include::DontR
On Thu, Oct 7, 2010 at 4:13 PM, Paul Johnson wrote:
> On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote:
>
> > Test::Include::DontRun
>
> I'll just point out that any name which includes DontRun rather than
> Don't::Run has sold its soul and should probably start with
> Com::Really
On Thu, Oct 07, 2010 at 12:36:41PM +0100, Charles Colbourn wrote:
> Test::Include::DontRun
I'll just point out that any name which includes DontRun rather than
Don't::Run has sold its soul and should probably start with
Com::ReallyBigCorporation::Enterprise::
Then I'll duck (low) and I will run.
On Thu, Oct 7, 2010 at 10:22 AM, Charles Colbourn <
charles.colbo...@googlemail.com> wrote:
> It works very simply, by wrapping the source of 'myscript.pl' in
> "{last; }'.
Well, as it seems it does no ->import(), but just compiles the code ...
Test::LegacyScript::Compile?
> There's som
--- Forwarded message --
> From: Charles Colbourn
> Date: 7 October 2010 10:10
> Subject: Re: Module naming - Test::Import::DontRun
> To: ebhans...@cpan.org
>
>
> @Eirik
>
>>>
>>> There's some complex and potentially slightly
>>> fragile
OK, I get what you want to do. I have seen this before. My brains being what
they are lately, I don't remember where but it was not so long ago. Maybe Andy
maybe someone else. Maybe even you ;)
So before you go further, you can, if you so wish, look around a bit.
I'm sure that other with better
Mea Culpa - it wasn't a very clear description.
OK, so perhaps you have a script like this:
###myscript.pl###
doStuff();
doOtherStuff();
sub doStuff{
# things that need testing
}
sub doOtherStuff{
# things you don't want to run
}
__END__
and you don't have the option of wrapping the top leve
I must admit that I didn't get what you mean. Care to enlighten me with a
piece of code, some flow, anything that doesn't make me feel stupid.
Nadim.
Message--
From: nadim khemir
To: module-authors@perl.org
Sent: Oct 5, 2010 2:58 AM
Subject: Re: Module Naming
You should have what type of device in the name too. The fact that it works
with serial port is not interesting and can be made clear in a sub module if
multiple communication medium e
Aurora is a type of inverter and serial is type of aurora however if inheriting
Device::Serial put that first
Device::Serial::Inverter::Aurora
--Original Message--
From: nadim khemir
To: module-authors@perl.org
Sent: Oct 5, 2010 2:58 AM
Subject: Re: Module Naming
You should have what
You should have what type of device in the name too. The fact that it works
with serial port is not interesting and can be made clear in a sub module if
multiple communication medium exist.
Device::Inverter::Aurora
Be more specific in the top classes if you can. The idea is to have a name for
If not Device::Aurora Perhaps something along the lines of
Device::SerialPort::Aurora ?
Or
Device::Serial::Protocol::Aurora (except that the module handles all the
SerialPort stuff too)
igBrother.
Sent from my BlackBerry® smartphone with Nextel Direct Connect
-Original Message-
From: sawyer x
Date: Sun, 10 Jan 2010 22:16:42
To: Paul LeoNerd Evans
Cc:
Subject: Re: Module naming suggestions : Test::DNS
Hi Paul, thanks for answering so quicky!
On Sun, Jan 10, 2010 at 8:37 PM,
On Sun, Jan 10, 2010 at 9:17 PM, Hans Dieter Pearcey <
hdp.perl.module-auth...@weftsoar.net> wrote:
> Excerpts from Paul LeoNerd Evans's message of Sun Jan 10 13:37:51 -0500
> 2010:
> > Your module doesn't seem to be doing this - perhaps something like
> > Check::DNS may be a more suitable name fo
Excerpts from Paul LeoNerd Evans's message of Sun Jan 10 13:37:51 -0500 2010:
> Your module doesn't seem to be doing this - perhaps something like
> Check::DNS may be a more suitable name for yours?
I was going to say something along those lines, but a) his module speaks TAP
(as most of Test:: doe
Hi.
On Sun, Jan 10, 2010 at 10:43 PM, Dana Hudes wrote:
> If you call it Test::DNSserver ?
> Not ::server bec that would imply you are a server when you are a client.
>
Calling it Test::DNSServer is like saying that Test::File should be called
Test::FS, IMHO. I'm not checking whether a DNS serv
Hi Paul, thanks for answering so quicky!
On Sun, Jan 10, 2010 at 8:37 PM, Paul LeoNerd Evans
wrote:
> Usually the Test:: heirarchy is for unit test modules; mostly things
> built on Test::Builder, et.al.
True. My module uses Test::Builder as well, and provides comfortable unit
tests for DNS que
Usually the Test:: heirarchy is for unit test modules; mostly things
built on Test::Builder, et.al. Such a module would be used to assert on
the behaviour of code under test.
I would expect, given the name, that Test::DNS would check the behaviour
of some module, perhaps by asserting it performs D
David Golden wrote:
> Tim Bunce wrote:
>> On Fri, May 26, 2006 at 11:26:22PM +0200, David Landgren wrote:
>>> Jeff Lavallee wrote:
of the SOAP::Lite details. Currently, I'm planning on calling it
Yahoo::Marketing. Yahoo::Marketing.pm itself would just serve as a
place holder (with
Tim Bunce wrote:
On Fri, May 26, 2006 at 11:26:22PM +0200, David Landgren wrote:
Jeff Lavallee wrote:
of the SOAP::Lite details. Currently, I'm planning on calling it
Yahoo::Marketing. Yahoo::Marketing.pm itself would just serve as a
place holder (with POD) for the time being, with all the me
On Fri, May 26, 2006 at 11:26:22PM +0200, David Landgren wrote:
> Jeff Lavallee wrote:
> >Hi all, before I upload a new module, I thought I'd make sure the
> >namespace I intend to use makes sense. I've been working on a set of
> >modules to make interacting with the next generation of Yahoo's
> >
Jeff Lavallee wrote:
Hi all, before I upload a new module, I thought I'd make sure the
namespace I intend to use makes sense. I've been working on a set of
modules to make interacting with the next generation of Yahoo's
marketing web services easier. The modules insulate the user from a lot
of
On Sat, Dec 03, 2005 at 12:22:16PM -0800, Ovid wrote:
> --- 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 t
# from Ovid
# on Saturday 03 December 2005 12:22 pm:
>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).
And eventually everyone in the thread (except the lis
--- 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 w
On Thu, 2005-01-06 at 20:08 -0600, David Nicol wrote:
> I don't understand what's being contemplated here.
> I think we're talking about recreating Package::Alias,
> which is essentially sugar around
>
> use really::long::name::ending::bar;
> BEGIN {
> *bar:: = \*really::long::name::ending::b
I don't understand what's being contemplated here.
I think we're talking about recreating Package::Alias,
which is essentially sugar around
use really::long::name::ending::bar;
BEGIN {
*bar:: = \*really::long::name::ending::bar::
}
after which the methods in RLNEB can be referred to
with the
* Alberto Manuel Brandao Simoes <[EMAIL PROTECTED]> [2005-01-06 21:19]:
> My 5 words...
>
> use aka Name Really::Lond::Module::Name qw(foo bar baz)
Except that's not valid syntax, and the version which would be
has already been discussed and dismissed.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{
A. Pagaltzis wrote:
* Jenda Krynicky <[EMAIL PROTECTED]> [2005-01-05 01:28]:
Has anyone ever seen a module with a space in the name? If not
we might just as well use
use aka 'Really::Long::Module::Name as MName' qw(foo bar baz);
How about this?
use aka [ 'Really::Long::Module::Name' => 'Name
* Jenda Krynicky <[EMAIL PROTECTED]> [2005-01-05 01:28]:
> Has anyone ever seen a module with a space in the name? If not
> we might just as well use
>
> use aka 'Really::Long::Module::Name as MName' qw(foo bar baz);
How about this?
use aka [ 'Really::Long::Module::Name' => 'Name' ] qw
Ken Williams wrote:
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.
I still don't understand the sem
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
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?
Ovid <[EMAIL PROTECTED]> writes:
[...]
> That fails because it makes the common case more difficult:
>
> use aliasing "Really::Long::Class:Name";
> # or
> use aliasing "Really::Long::Class:Name", as => "CName";
>
> However, I do like the name "aliasing.pm" Anyone else? It's not
> perfect
# The following was supposedly scribed by
# Jenda Krynicky
# on Tuesday 04 January 2005 06:28 pm:
>Has anyone ever seen a module with a space in the name? If not we
>might just as well use
>
>use aka 'Really::Long::Module::Name as MName' qw(foo bar baz);
Right. No, it's not even possible to
--- Sam Vilain <[EMAIL PROTECTED]> wrote:
> However, this code reads very well:
>
> use module 'Foo::Bar' as 'Bar';
> use package 'Foo::Bar' as 'Bar';
'package' is a reserved word, so I won't use that. 'module' is worse
than 'class' because 'class' at least let's us know that this pragma is
David Wheeler wrote:
I agree that it should be lowercased; yes, there are modules on CPAN
that look like pragmas (such as only). I personally would prefer,
however, that the name tell me that it's doing something more than
loading a class; "class" and "module" don't do that.
However, this code
From: Ovid <[EMAIL PROTECTED]>
> --- 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.
Agreed.
> > As for the interface, I rea
On Tue, 2005-01-04 at 18:29 -0500, Randy W. Sims wrote:
> There is Package::Alias[1]. Does the same thing, but I haven't used it.
>
Upon a quick glance, this does a similar thing but via a different
mechanism.
Ovid's module installs a constant sub into the caller's namespace which
returns the lo
--- 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 confused with 'Alias.pm'.
Whic
# The following was supposedly scribed by
# David Wheeler
# on Tuesday 04 January 2005 04:55 pm:
>I agree that it should be lowercased; yes, there are modules on CPAN
>that look like pragmas (such as only). I personally would prefer,
>however, that the name tell me that it's doing something more t
On Tue, Jan 04, 2005 at 02:55:08PM -0800, David Wheeler wrote:
> On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote:
>
> >I've always felt that this one should have a lowercase name, since it's
> >rather pragma-ish. Are pragmas allowed outside of the core Perl
> >distribution? Maybe it should be s
David Wheeler wrote:
On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote:
I've always felt that this one should have a lowercase name, since it's
rather pragma-ish. Are pragmas allowed outside of the core Perl
distribution? Maybe it should be submitted as a core pragma, actually.
It's a really light
"aka" is cool. I'll throw a few suggestions:
* mask
* camo
* pose
* cover
* veil
* guise
But yeah, "aka" is probly the best bet.
On Tue, Jan 04, 2005 at 02:55:08PM -0800, David Wheeler wrote:
> On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote:
>
> >I've always felt that this one should have a
On Jan 4, 2005, at 2:47 PM, Bruce J Keeler wrote:
I've always felt that this one should have a lowercase name, since it's
rather pragma-ish. Are pragmas allowed outside of the core Perl
distribution? Maybe it should be submitted as a core pragma, actually.
It's a really lightweight beast, and ver
On Tue, 2005-01-04 at 12:49 -0800, Ovid wrote:
> Hi all,
>
> I'm about to release "Aliased" to the CPAN. Yeah, it's a root level
> name, but it will soon become clear why it needs to be short.
>
> [...]
I've always felt that this one should have a lowercase name, since it's
rather pragma-ish.
My only quibble is that alias is 'less cumbersome' than aliased---sadly
already used...
--hsm
p.s. nice idea!!
> -Original Message-
> From: Ovid [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 04, 2005 1:49 PM
> To: module-authors@perl.org
> Subject: Module naming advice
>
> Hi all,
>
--- Kurt Starsinic <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Jan 2005 12:49:16 -0800 (PST), Ovid
> <[EMAIL PROTECTED]> wrote:
> > I'm about to release "Aliased" to the CPAN.
> >
> > [ . . . . ]
> >
> > Basically, when you have long package names, it can be cumbersome
> to
> > retype the package name a
On Tue, 4 Jan 2005 12:49:16 -0800 (PST), Ovid
<[EMAIL PROTECTED]> wrote:
> I'm about to release "Aliased" to the CPAN.
>
> [ . . . . ]
>
> Basically, when you have long package names, it can be cumbersome to
> retype the package name all the time. This module allows you to skip
> that if the subro
78 matches
Mail list logo