Re: Module Naming & Relevancy

[David Cantrell]

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 is the polite and reasonable thing to do. 
I'm sure it's not the only web service out there called Pacer, and if 
there is another then Brian's isn't any more important than they are.


--
David Cantrell

Re: Module Naming & Relevancy

[Pero Moretti]

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 qualification would be at the other end...
WebService::PACER::USCourt (for example).

But PACER could be a term that is eventually overloaded when someone else
names their own unrelated Web service PACER. While only a slim possibility
I don't think forwardly ensuring unambiguous module naming wouldn't be a
bad idea.

Just my 2c worth. :)


On Sat, Jun 11, 2022, 10:01 Tim Ka  wrote:

> 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 don’t think that’s
>> necessary – better to keep things simple.
>>
>> Cheers,
>> Neil
>>
>

Re: Module Naming & Relevancy

[Tim Ka]

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 don’t think that’s necessary
> – better to keep things simple.
>
> Cheers,
> Neil
>

Re: Module Naming & Relevancy

[Neil Bowers]

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

Re: Module Naming & Relevancy

[David Christensen]

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 before US district courts, US court of
appeals, or US bankruptcy courts.

https://pacer.uscourts.gov/about-us

While the PACER API enables relatively easy access to the service, a module
in CPAN would increase accessibility.  Increasing public access to court
records could result in unforeseen good.  There are several Python projects
on GitHub.com for interfacing with PACER.

Before I started developing this module, I searched CPAN for existing code
but found nothing relevant.  I've found modules for getting US Census,
Postal Service, as well as Treasury Department's OFAC (Office of Foreign
Assets Control) data but nothing related to the judicial system of any
country.

Any suggestions for an appropriate package name?  I was thinking perhaps
Court::US::PACER or USCourt::PACER.

I appreciate any and all comments.

-Brian Erickson



It appears that 'WWW' is the appropriate top-level CPAN name for Perl 
distributions that provide programmatic interfaces to web servers:


https://metacpan.org/search?q=www


(It also appears that those authors stripped the TLDN from the target 
server FQDN when naming their distributions.  That may have seemed okay 
30 years ago, but I would advise against it today.)



'WWW' followed by the reverse fully-qualified domain name of the server 
would make sense to me:


WWW::Gov::USCourts::PACER


David

Re: Module naming advice, please.

[Rory McKinley]

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::Spoor - I will hold off on Spoor:: until I am sure it is not
just hurbis talking :).

Thanks again!

On Wed, 23 Jan 2019 at 21:02, Doug Bell  wrote:

> > 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::Client, but that
> will mean that I will be creating a new top-level name which I know is
> discouraged. Is there a suitable top-level name that I could host my client
> under, or would grabbing the Spoor name be ok under these circumstances?
>
> If it's a web service, I'd say use WWW:: or WebService::. If it's an OSI
> Layer 7 protocol like HTTP, I'd go with Net::. If all else fails,
> API::Spoor wouldn't be a terrible idea.
>
>
> Doug Bell
> d...@preaction.me
>


-- 
Rory McKinley
Director
Cape Fox Consulting (Pty) Ltd
Registration No: 2015/388067/07
Director(s): R McKinley

Re: Module naming advice, please.

[Doug Bell]

> 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::Client, but that will 
> mean that I will be creating a new top-level name which I know is 
> discouraged. Is there a suitable top-level name that I could host my client 
> under, or would grabbing the Spoor name be ok under these circumstances?

If it's a web service, I'd say use WWW:: or WebService::. If it's an OSI Layer 
7 protocol like HTTP, I'd go with Net::. If all else fails, API::Spoor wouldn't 
be a terrible idea.


Doug Bell
d...@preaction.me

Re: Module naming advice, please.

[Timothe Litt]

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. 
>
> My current inclination is to call the module Spoor::Client, but that
> will mean that I will be creating a new top-level name which I know is
> discouraged. Is there a suitable top-level name that I could host my
> client under, or would grabbing the Spoor name be ok under
> these circumstances?
>
> Thanks in advance
>
> Rory 
>
> -- 
> Rory McKinley
> Director
> Cape Fox Consulting (Pty) Ltd
> Registration No: 2015/388067/07
> Director(s): R McKinley


signature.asc
Description: OpenPGP digital signature

Re: Module naming - exposing Win API function ShellExecute

[Chase Whitener]

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

CreateProcess:
I might be off base, but maybe https://metacpan.org/pod/Win32::Daemon can
help here.

Outside of that, I'd likely continue in the vein of Win32::Foo for naming
conventions.

Thanks,
Chase


On Tue, Nov 13, 2018 at 12:05 PM Timothy Madden 
wrote:

> Hello,
>
> For ::ShellExecute API function on Windows I got confused with the
> possible names like:
>
>   - Win32::ShellExecute
>   - Win32::API::ShellExecute
>   - Win32API::ShellExecute
>
> I noticed Win32API:: namespace mostly uses XS modules to expose the API,
> while my module uses dynamic loading of .dll files with Win32::API. Some
> people say this is not as good as the equivalent XS binding, though it
> is not clear for me why and I much prefer pure-perl modules for
> distribution / installation reasons.
>
> I also need some names for a couple of modules like:
>
>   - Win32::CmdQuote::Simple, for command quoting in a safe and strict
> manner, as this is a big issue on Windows
>
>   - Win32::API::Error, for a base exception class that encapsulates the
> error message and error code from ::GetLastError()
>
>   - Win32::API::CreateProcess - there is a module available that exposes
> only part of the call interface of the C function, so I would need a
> more detailed module (the function argument list is rather complicated
> for this one).
>
> I am a bit worried about the proper names as I notice Win32:: and
> Win32API:: modules are included by default with the Windows version of
> perl (I use Strawberry). I also believe there is a need for more API
> functions exposed in the language for the Windows platform.
>
> Any suggestions appreciated,
>
> --
> Thank you,
> Timothy Madden
>

Re: Module Naming: a Path::Iter::Rule subclass which scans FTP sites

[Diab Jerius]

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!

Re: Module naming -- processing 3D JPEG files...

[Timothe Litt]

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 images?

Alternatively, might one pair for other reasons?  (Image::Pair::format)?

Image::Group::Stereo::format?

Image::Container::Stereo::format?

Image::Composite::Holo::JPG?

Image::Diffraction::XRay::bmp?

Image::Resonance::Slice::tiff?

Not my field, obviously.  But I do wonder if taking a second level
namespace for this is the best choice...

Of course, no one wants infinitely long names.  But maybe there's a
happy medium.  (Sorry, no pun intended.)

I'm not necessarily opposed to "stereo" (nor would it matter if I were),
but you asked for feedback, and that's what comes to mind...

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 02-May-17 23:20, BC wrote:
> Oh great and wise sages of the CPAN wisdom,
>
> I'd like some feedback and advice for naming some modules I am
> contemplating.
>
>Image::Stereo::MPO
>Image::Stereo::JPS
>Image::Stereo::JPG
>
> These would be modules used for basic manipulation of
> stereographic JPEG-based images.
>
> Here's a bit of background for the interested.
>
> MPO -- Multi-Picture Format
>
>Digital 3D cameras (yes, there are such things) most commonly
>store L/R images as a pair of JPEG files in a container file
>with the extension ".MPO".  The container file also contains
>additional meta data, beyond the standard JPEG fields, that
>describes relationships between the images.  (Actually, to be
>more accurate, MPO files can store any number of related
>images, such as for panoramics.  But in practice, in the wild,
>MPO files contain stereographic pairs.)
>
> JPS -- JPEG Stereo Format
>
>Another older format for stereographic pairs has an extension
>of ".JPS".  This is a JPEG file with the R/L images 'glued'
>together side-by-side and some additional meta data (EXIF).
>
> JPG
>
>And L/R stereo pairs are often just combined into a single
>JPEG file without any special meta data and may be in a
>side-by-side or under-over format.
>
> A common thing to want to do is to take L/R stereo pair of JPEG
> files and combine them into a single MPO or JPS file, and
> likewise take an MPO or JPS file and split it out into two
> separate JPEG files.  That's what these modules will do.
>
> OK -- probably more than you wanted to know.
>
> As for the module names, stereographic images are commonly
> referred to as 3D images, but there are other associations for
> the term, plus I'm guessing that "::3D::" would be a no-no for
> CPAN module naming.  Stereographic images are also shorthanded as
> just "stereo" which is a more reasonable name length.
>
> ...BC
>

Re: Module Naming: a Path::Iter::Rule subclass which scans FTP sites

[Reini Urban]

Thinking about it, I like the name Net::FTP::Path::Iter best

Reini Urban
rur...@cpan.org

Re: Module Naming: a Path::Iter::Rule subclass which scans FTP sites

[Diab Jerius]

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 (the current working name)
> is just plain opaque.
>
> * Path::Iter::Rule::FTP
> seems backwards. FTP should be up front.  On the other hand, maybe PIR
> will one day have a plugin system and will automatically choose a backend
> based on the input path.  That would be cool!
>
> * Path::FTP::Iter::Rule
> I think FTP should be up front
>
>
> * Net::FTP::Path::Iter::Rule
> is really long, but has all of the key elements in it.
>
> * Net::FTP::Iter::Rule
> doesn't imply anything about a path, so I'm not sure what it does.
>
> ​​​Any suggestions?
>
> Thanks!
>
> Diab
>
> [1] https://metacpan.org/pod/release/DJERIUS/Net-FTP-Rule-
> 0.01-TRIAL/lib/Net/FTP/Rule.pm
>

RE: Module naming -- processing 3D JPEG files...

[BC]

 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

--
---[ bill.co...@alumni.unh.edu ]--
 Bill Costa
 New Hampshire, USA
 http://pubpages.unh.edu/~wfc
 WORK: +1-603-862-3056
 HOME: +1-603-435-8526
[ No good deed... Goes unpunished. ]--

Re: Module naming -- processing 3D JPEG files...

[Dan Book]

>
> 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 an uppercase letter as the
> first character?


A number as the first character of a subnamespace is fine, as long as it is
not the first character of the whole package name.

-Dan

RE: Module naming -- processing 3D JPEG files...

[BC]

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 binoculars.


Not my field, obviously.  But I do wonder if taking a second
level namespace for this is the best choice...


Your point about trying to narrow it down to image pairs is well
taken.  Referring to the images themselves as 'stereo pairs' or
'3D pairs' is very common in the stereographic community.


What about other composite views that make an image appear to
have depth/perspective?


There are indeed other stereographic formats that can involve
more than two images.  For example 3D lenticulars are best done
with arrays of at least 3 or more images and there have been many
3D cameras that have been purpose-built for the technique:

https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Nimslonew.jpg/300px-Nimslonew.jpg

http://www.3dham.com/stereo_cameras/Nishikacamera320.jpg

And of course static 3D VR images, and 3D panoramic images can
also involve using an array of images beyond single pairs.


E.g. Hologram (Holo?)  Is there a term that covers the space of
all composite views and/or related images?


It sometimes gets applied that way, but a hologram is a unique
and different process that yields a true 3 dimensional image of
an object not a scene.  You can think of VR as an image that
surrounds the viewer, where with holography the viewer can
surround an object.

And of course, 3D images can also be generated from 3D computer
modeling, and capturing depth maps.

https://en.wikipedia.org/wiki/Depth_map

https://phys.org/news/2016-06-imaging-technique-image-depth-monocular.html

As for the 2nd level, the term stereographic is certainly the
least ambiguous, since 'stereo' by itself is even more commonly
used to mean stereophonic.  So you could do:

   Image::Stereographic::Pairs::MPO
   Image::Stereographic::Pairs::JPS
   Image::Stereographic::Pairs::JPG

   Image::Stereographic::Lenticular
   Image::Stereographic::VR
   Image::Stereographic::Holo
   Image::Stereographic::DepthMap

But this feels like something out of the Department of Redundancy
Dept. since what you are saying is "image-solid-image". (Stereo
is the Greek word for solid.)

So alternatively, the more concise:

   Image::Stereo::Pairs::MPO
   Image::Stereo::Pairs::JPS
   Image::Stereo::Pairs::JPG

   Image::Stereo::Lenticular
   Image::Stereo::VR
   Image::Stereo::Holo
   Image::Stereo::DepthMap

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 an uppercase letter as the
first character?

So I'm thinking the "stereo" 2nd level namespace proposal would
be a good balance between descriptiveness and brevity, and
taxonomically I think you can argue that "Image::Stereo" is
unambiguous.  But "3D" looks good to me too, if it is allowed.

...BC

--
---[ bill.co...@alumni.unh.edu ]--
 Bill Costa
 New Hampshire, USA
 http://pubpages.unh.edu/~wfc
 WORK: +1-603-862-3056
 HOME: +1-603-435-8526
[ No good deed... Goes unpunished. ]--

Re: Module naming -- processing 3D JPEG files...

[James E Keenan]

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.

Smylers



I concur with Smylers.  +1

Re: Module naming -- processing 3D JPEG files...

[Timothe Litt]

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 images?

Alternatively, might one pair for other reasons?  (Image::Pair::format)?

Image::Group::Stereo::format?

Image::Container::Stereo::format?

Image::Composite::Holo::JPG?

Image::Diffraction::XRay::bmp?

Image::Resonance::Slice::tiff?

Not my field, obviously.  But I do wonder if taking a second level
namespace for this is the best choice...

Of course, no one wants infinitely long names.  But maybe there's a
happy medium.  (Sorry, no pun intended.)

I'm not necessarily opposed to "stereo" (nor would it matter if I were),
but you asked for feedback, and that's what comes to mind...

On 02-May-17 23:20, BC wrote:
> Oh great and wise sages of the CPAN wisdom,
>
> I'd like some feedback and advice for naming some modules I am
> contemplating.
>
>Image::Stereo::MPO
>Image::Stereo::JPS
>Image::Stereo::JPG
>
> These would be modules used for basic manipulation of
> stereographic JPEG-based images.
>
> Here's a bit of background for the interested.
>
> MPO -- Multi-Picture Format
>
>Digital 3D cameras (yes, there are such things) most commonly
>store L/R images as a pair of JPEG files in a container file
>with the extension ".MPO".  The container file also contains
>additional meta data, beyond the standard JPEG fields, that
>describes relationships between the images.  (Actually, to be
>more accurate, MPO files can store any number of related
>images, such as for panoramics.  But in practice, in the wild,
>MPO files contain stereographic pairs.)
>
> JPS -- JPEG Stereo Format
>
>Another older format for stereographic pairs has an extension
>of ".JPS".  This is a JPEG file with the R/L images 'glued'
>together side-by-side and some additional meta data (EXIF).
>
> JPG
>
>And L/R stereo pairs are often just combined into a single
>JPEG file without any special meta data and may be in a
>side-by-side or under-over format.
>
> A common thing to want to do is to take L/R stereo pair of JPEG
> files and combine them into a single MPO or JPS file, and
> likewise take an MPO or JPS file and split it out into two
> separate JPEG files.  That's what these modules will do.
>
> OK -- probably more than you wanted to know.
>
> As for the module names, stereographic images are commonly
> referred to as 3D images, but there are other associations for
> the term, plus I'm guessing that "::3D::" would be a no-no for
> CPAN module naming.  Stereographic images are also shorthanded as
> just "stereo" which is a more reasonable name length.
>
> ...BC
>



signature.asc
Description: OpenPGP digital signature

Re: Module naming -- processing 3D JPEG files...

[Smylers]

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/Smylers2

Re: Module naming collision Or mirage?

[Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯]

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 unauthorised release because you do not have the
permissions on that namespace. Indexes list those releases separately
(and in scary big red letters!). This means a user will not be able to
install your `Math::Simple` module by the module name alone (because
this would resolve to the `Inline` distribution), but needs a qualified
name such as `LAWALSH/Math-Simple-2.000.tar.gz` or a URL. Naturally,
your version must be greater than the existing 1.23.

Read http://pause.perl.org/pause/query?ACTION=pause_04about for
further details.

 Should it even be listed as a module?

No, example packages should not be indexed. File a bug with `Inline`,
state your intentions of taking over the namespace for a
different/greater purpose, ask for PAUSE permissions on the namespace,
tell how to prevent that further releases of Inline show up indexed
with `Math::Simple` (either http://p3rl.org/CPAN::Meta::Spec#no_index
or the hack where the `package` keyword and the namespace literal are
declared across two lines, I forgot where this is documented),
optionally provide a Makefile.PL patch/distribution meta file that
achieves this.


signature.asc
Description: PGP signature

Re: Module naming and a couple other questions

[Joshua Megerman]

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 that), and this is intended to let non-Win32 platforms interface with the 
WMI services that run on WIndows.  Using Net:: as the top-level would work, as 
this is a wire protocol.

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.

3. Since much of the code is already GPL (and a bunch of the code I wrote i 
modifications to that), I'll probably just distribute the whole thing as GPL, 
and make it simple.  My code is pretty much worthless without the GPL code, so 
there's no real reason not to make it so.

4. I'll look into Module::Build and using prompt() - this whole project has 
been my first venture into building a packaged module (as opposed to something 
I just built for myself/internal use), so I started simple :).  I'm not real 
keen on using Alien, despite its obvious usefulness in ensuring that the 
required source is available and configured properly.  Given the limited 
audience for this module, I'm comfortable assuming that anyone who needs it 
can follow directions (even though I'm sure that'll bite me someday...).

Thanks for the input - I appreciate it!

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
j...@honorablemenschen.com

Re: Module naming and a couple other questions

[Buddy Burden]

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.

Bearing in mind that I am but one voice, and therefore taking my
opinion with the appropriate number of grains of salt, I'll give you
my view on the question of to export or not to export.

When a module has several functions that I may or may not need, I
prefer it to export nothing (e.g. List::Util, List::MoreUtils).  When
it has exactly one function, and my use of that function is the entire
point of my including the module in the first place, I prefer it to
export that function (e.g. Date::Format, Date::Parse).  Even if it's
two functions, if they're very closely related, I'd prefer them to be
exported by default (e.g. File::Basename).  When a module has exactly
one purpose in life, which is to call a function, and it doesn't
export it (e.g. Sub::Install), that irks me a little bit, as it forces
me to do it myself, and it just seems redundant.  As Eric mentions,
it's not like I don't know how to stop the export if I really don't
want it.

Just my perspective, mostly as a user rather than author (but also an
author of a few things here and there).


-- Buddy

Re: Module naming and a couple other questions

[Smylers]

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
 software and provides a method of calling the WMI client without forking
 to use the wmic binary.  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 and Win32::WMIC, both of which
 collect and parse the output of `wmic`, which is what my module is
 designed to avoid.  Suggestions on the best way to name it would be
 greatly appreciated.

After reading that, I'm afraid I'm still unclear on what your module
does; WMI isn't something I've heard of before.

If it's something only of use with Windows, then putting under the
Win32:: namespace would be useful, to clearly demark that.

Using a suffix ::Client is probably better than Client, if you think a
suffix is needed at all. Could an equivalent ::Server module ever be
uploaded? Or are all users of WMI effectively clients of it, so ::Client
is redundant.

 2. Said module currently has 1 function, wmiclient, which I was planning
 on exporting by default.  I see that it's generally recommended not to do
 that,

Make uses import the function explicitly. If you later regret that
decision, you could change to exporting it by default. Whereas if you
initially export it by default, you're stuck with continuing to do that
in later versions, so you don't break code of people relying on it.

 3. The module uses several chunks of C code from the WMI package itself,
 which are distributed under the GPL.  My initial license thought was to
 distribute the .xs file as GPL with the rest of the module package under
 the same terms as Perl itself, but I don't know if that's a valid
 licensing model.  Can I do that, or do I need to distribute the entire
 module as GPL (which is OK with me).  Is this a problem for distribution
 via CPAN?

Distributing the entire thing as GPL is certainly fine by Cpan, and
would definitely comply with the WMI package's terms.

You could put a note in the doc asking people to contact you if they
would find your module more useful under a different licence. That way
you can postpone researching the matter further until somebody does (or
possibly never).

Cheers

Smylers
-- 
New series of TV puzzle show 'Only Connect' (some questions by me)
Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect

Re: Module naming and a couple other questions

[Eric Wilhelm]

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 and Win32::WMIC,

I would say Win32::WMIClient if it only run on windows.  If this is a 
wire protocol, you might consider NET:: (sorry it does not google well 
for me -- but your libasync_wmi_lib.so mention seems to point away from 
Win32::.)


2. Said module currently has 1 function, wmiclient, which I was
planning on exporting by default.  I see that it's generally
recommended not to do that,

In the case of providing one function, it might make more sense to 
export it by default.  One can always disable the import with a `use ... 
()`, so nobody is trapped by your decision.  But, it is good practice to 
import functions explicitly or call them with an absolute name because 
it provides a better answer to how did this function get into my 
namespace?

Can I do that, or do I need to distribute the entire module as GPL...

I [am not a lawyer] think you can use copyright law to grant anyone 
whatever license you like _on the code you wrote_.  The GPL will apply 
to the usage of everything together once they are linked/executed, so 
your license has to allow for that.


...Is this a problem for distribution via CPAN?

No.  (I was trying to track down the reference for this and I'm not sure 
if there's more written on this topic.  Basically:  as long as your 
license doesn't prevent it from being freely and widely mirrored and you 
are not abusing the generosity of the mirrors, it can be on the CPAN.)

  http://www.cpan.org/misc/cpan-faq.html#Does_CPAN_allow_shareware


4. In order to successfully build this module, you need to have the
WMI library installed and specify the location of the WMI source code
as a parameter to 'perl Makefile.PL' so it can find the necessary
headers (which I'd rather not have to package with the module
source).  I have specified this in the README and Makefile.PL, but I
don't know how to handle that requirement via CPAN.

A parameter to Makefile.PL is not going to work well with a CPAN client.  
If you want to make it really smooth for users, take a look at some of 
the Alien:: modules -- you could perhaps automate the installation with 
an Alien::WMI package.  Alternatively, you could prompt() in your 
Makefile.PL.


5. I'm only starting to look into testing now, but one of the
requirements for testing this thoroughly will be that information be
passed regarding username/password and machine to test
against.

If you must have a live test, maybe use prompt() -- but be aware that 
you would be storing that password as plaintext as a side-effect of how 
the makefile/make process works.  You might be able to work something 
into the test action -- prompt just before running the tests and put the 
password in an environment variable.  (I [am biased] would use 
Module::Build for that level of customization rather than MakeMaker.)


--Eric
-- 
---
http://scratchcomputing.com
---

Re: Module naming: postifx/dovecot/MySQL configuration

[Aristotle Pagaltzis]

Hi Avi,

* Avi Greenbury li...@avi.co [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.

neither is Mail::vpopmail.

https://metacpan.org/module/Mail::vpopmail#AUTHOR
http://vpopmail.svn.sourceforge.net/viewvc/vpopmail/trunk/doc/AUTHORS?view=markup

It’s the exception rather than the norm that a module on CPAN which
interfaces with XYZ is written by the XYZ project/owners themselves.

I’d argue for this name.

 It's currently called Mail::Vpostmail (since originally it was to be
 a postfix clone of the Vpopmail utilities and it must have seemed like
 a reasonable pun at the time).

It made me think your module is about sending mail in some way… esp. so
since you had just mentioned vpopmail.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: Module naming: postifx/dovecot/MySQL configuration

[Bill Ward]

Mail::Postfixadmin seems fine to me

On Tue, Dec 13, 2011 at 5:06 AM, Avi Greenbury li...@avi.co 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 domains/users stored
 in MySQL. I'd like to upload it to the CPAN, and I'm after some advice
 on what to call it first.

 The closest I can find on the CPAN is VUser::Email::Postfix which is
 part of VUser.

 There's also Mail::Vpopmail which is exactly the same in purpose, but
 for Vpopmail rather than postfixadmin.

 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.

 It's currently called Mail::Vpostmail (since originally it was to be a
 postfix clone of the Vpopmail utilities and it must have seemed like a
 reasonable pun at the time).

 I've got a bunch of work to do on it over Christmas, and I figure that
 that's also as good a time as any to rename it in preparation for making
 it more public and check everything still works.

 Thanks!

 --
 Avi

 [0] http://sourceforge.net/projects/postfixadmin/




-- 
Check out my LEGO blog at http://www.brickpile.com
Follow/friend me: facebook.com/billward • flickr.com/photos/billward •
twitter.com/williamward

Re: Module Naming Suggestion - Carp from somewhere else

[Bill Ward]

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
leon...@leonerd.org.ukwrote:

 (To copypaste
 http://leonerds-code.blogspot.com/2011/03/carp-from-somewhere-else.html ):

 Carp provides two main functions, carp and croak, as replacements for
 core Perl's warn and die. The functions from Carp report the file and
 line number slightly differently from core Perl; walking up the
 callstack looking for a different package name. The idea being these are
 used to report errors in values passed in to the function, typically bad
 arguments from the caller.

 These functions use the dynamic callstack (as provided by caller()) at
 the time the message is warned (or thrown) to create their context. One
 scenario where this does not lead to sensible results is when the called
 function is internally implemented using a closure via some other
 package again.

 Having thought about this one a bit, it seems what's required is to
 split collecting the callstack information, from creating the message.
 Collect the information in one function call, and pass it into the
 other.

 This would be useful in CPS for example. Because the closures used in
 CPS::kseq or kpar aren't necessarily invoked during the dynamic scope of
 the function that lexically contains the code, a call to croak may not
 be able to infer the calling context. Even if they are, the presence of
 stack frames in the CPS package would confuse croak's scanning of the
 callstack. Instead, it would be better to capture the calling context
 using whence, and pass it into whoops if required for generating a
 message.

 For example, this from IO::Async::Connector:

 sub connect
 {
   my ( %params ) = @_;
   ...

   my $where = whence;

   kpar(
  sub {
 my ( $k ) = @_;
 if( exists $params{host} and exists $params{service} ) {
my $on_resolve_error = $params{on_resolve_error} or whoops
 $where, Expected 'on_resolve_error' callback;
...
 }

 These functions would be a fairly simple replacement of carp and croak;
 capture the callsite information at entry to a function, and pass it to
 the message warning function.

 It does occur to me though, the code will be small and self-contained,
 and not specific to CPS. I think it ought to live in its own module
 somewhere - any ideas on a name?

 --
 Paul LeoNerd Evans

 leon...@leonerd.org.uk
 ICQ# 4135350   |  Registered Linux# 179460
 http://www.leonerd.org.uk/

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iD8DBQFNcihqvLS2TC8cBo0RAuSrAJ9omaYwINWa31kEAh3jQtgjI03sMACePZzP
 VbxfM0a4TuhPoJijNBwu2eg=
 =Fg2o
 -END PGP SIGNATURE-




-- 
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: Module naming - Test::Import::DontRun

[Charles Colbourn]

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 p...@pjcj.net 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::ReallyBigCorporation::Enterprise::

 Then I'll duck (low) and I will run.

 --
 Paul Johnson - p...@pjcj.net
 http://www.pjcj.net

Re: Module naming - Test::Import::DontRun

[Charles Colbourn]

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.

charles.


On 8 October 2010 09:25, Charles Colbourn
charles.colbo...@googlemail.com wrote:
 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 p...@pjcj.net 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::ReallyBigCorporation::Enterprise::

 Then I'll duck (low) and I will run.

 --
 Paul Johnson - p...@pjcj.net
 http://www.pjcj.net

Re: Module naming - Test::Import::DontRun

[nadim khemir]

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.

Re: Module naming - Test::Import::DontRun

[Charles Colbourn]

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 level scope
('doStuff();doOtherStuff()') in 'if caller(){}' - maybe it's legacy
code that is running fine in production, and you don't want to modify
it.

The idea is your test script looks like this:

use Test::Import::DontRun qw(myscript.pl);
my $res = doStuff();
cmp_ok($res,eq,Some or other value);


It works very simply, by wrapping the source of 'myscript.pl' in
{last; code }'. There's some complex and potentially slightly
fragile stuff to handle @EXPORT if you want to, but the basic case
works pretty well.

I hope that's clearer. Feel free to say 'what a stupid idea' or 'that
won't work because' incidentally - but so far I've found it pretty
useful.

thanks,

Charles.





On 7 October 2010 09:02, nadim khemir na...@khemir.net wrote:
 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.

Re: Module naming - Test::Import::DontRun

[nadim khemir]

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 memory than I have will help.

And, NO, it's not a stupid idea.

Nadim.

Re: Module naming - Test::Import::DontRun

[Charles Colbourn]

Just a passing thought - Test::Import::* suggests the import of data,
rather than code.

The generic name for importing code into the current namespace would
be 'include' I guess, so how about

Test::Include::DontRun

?



On 7 October 2010 10:11, Charles Colbourn
charles.colbo...@googlemail.com wrote:
 -- Forwarded message --
 From: Charles Colbourn charles.colbo...@googlemail.com
 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 stuff to handle @EXPORT if you want to, but the basic case
 works pretty well.

   Whoops.  What would your legacy script(?) use @EXPORT for?

 Some of the code I'm testing in our own legacy codebase includes
 modules that 'do things' when use'd or require'd, and also export
 methods via @EXPORT. My code attempts to handle this by duplicating
 the @EXPORT* declarations outside the anonymous scope. It does this
 simply by parsing the code and finding the appropriate strings. You
 can switch this behaviour off if need be, although I'm tempted to make
 it default to 'off' since it may not be as robust as the rest.



   (I'd be more concerned about __END__, __DATA__, __FILE__, and __LINE__.
 Okay, the latter two could be handled with a #line directive, but to handle
 the first two right, it seems you'd have to parse Perl ... or drop the {}s?)

 Eirik++ I'd overlooked those. I'll see what I can do with it, write
 some test cases etc.


 @Nadim

 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've had a dig around CPAN, and sifted through 'Perl testing, a
 developers notebook' and not found anything. I think I did bandy this
 idea around about 6 months ago, but the version I had then depended on
 modifying the legacy code, and was a glorified version of:
 {
 if (caller()){last}
 #code
 }

 So perhaps that was it? I don't think I posted here about it, but I
 may have mentioned it in the CB on Perlmonks, and I definitely floated
 the idea past a couple of people. OTOH if there's something around
 that does this already, that would save me some work :-)

Re: Module naming - Test::Import::DontRun

[Eirik Berg Hanssen]

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; code }'.


  Well, as it seems it does no -import(), but just compiles the code ...

  Test::LegacyScript::Compile?



 There's some complex and potentially slightly
 fragile stuff to handle @EXPORT if you want to, but the basic case
 works pretty well.


  Whoops.  What would your legacy script(?) use @EXPORT for?

  (I'd be more concerned about __END__, __DATA__, __FILE__, and __LINE__.
Okay, the latter two could be handled with a #line directive, but to handle
the first two right, it seems you'd have to parse Perl ... or drop the {}s?)



 I hope that's clearer. Feel free to say 'what a stupid idea' or 'that
 won't work because' incidentally - but so far I've found it pretty
 useful.


  (I won't call the idea stupid, but in any context where cleaning up the
code is an option, it would be the better one.)


Eirik

Re: Module naming - Test::Import::DontRun

[Paul Johnson]

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.

-- 
Paul Johnson - p...@pjcj.net
http://www.pjcj.net

Re: Module naming - Test::Import::DontRun

[Bill Ward]

On Thu, Oct 7, 2010 at 4:13 PM, Paul Johnson p...@pjcj.net 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::ReallyBigCorporation::Enterprise::

 Then I'll duck (low) and I will run.

 Yeah, but in Perl 5 the ' has been superseded with :: so you need to use
Test::Include::Don::tRun ;-)

Re: Module Naming

[nadim khemir]

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 
your module and still let other people use the top same classification

Device::Inverter::Solar::Aurora::PVI-3

later you can make it clear that you support serial communication if it has 
any importance

Device::Inverter::Solar::Aurora::PVI-3::Protocol::Serial

IMO, Device::Serial::Protocol::Aurora describes a device which purpose it to 
be a generic serial interface.

It _really_ doesn't matter if the module name is a mouth full.

Nadim.

Re: Module Naming

[Dana Hudes]

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 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 
your module and still let other people use the top same classification

Device::Inverter::Solar::Aurora::PVI-3

later you can make it clear that you support serial communication if it has 
any importance

Device::Inverter::Solar::Aurora::PVI-3::Protocol::Serial

IMO, Device::Serial::Protocol::Aurora describes a device which purpose it to 
be a generic serial interface.

It _really_ doesn't matter if the module name is a mouth full.

Nadim.


Sent from my BlackBerry® smartphone with Nextel Direct Connect

Re: Module Naming

[Shannon Wynter]

 I'm not sure including Solar or PVI-3 is going to be really 
appropriate as the protocol works for their wind inverters, and as far 
as I've seen it's the same protocol used in their 10, and even 100+kw 
models.


Some models however also support an Ethernet port, so I'm not entirely 
sure whether that's web based, or terminal based or something.


It doesn't inherit from SerialPort, it just makes use of SerialPort

I'm leaning to Device::Inverter::Aurora::Serial that way at a later 
point if someone gets the urge to build an Ethernet module they can call 
theirs Device::Inverter::Aurora::TCP or something.


How's that sound?

On 05/10/10 21:11, Dana Hudes wrote:

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 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
your module and still let other people use the top same classification

Device::Inverter::Solar::Aurora::PVI-3

later you can make it clear that you support serial communication if it has
any importance

Device::Inverter::Solar::Aurora::PVI-3::Protocol::Serial

IMO, Device::Serial::Protocol::Aurora describes a device which purpose it to
be a generic serial interface.

It _really_ doesn't matter if the module name is a mouth full.

Nadim.


Sent from my BlackBerry® smartphone with Nextel Direct Connect

Re: Module Naming

[Shannon Wynter]

 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)

Re: Module naming suggestions : Test::DNS

[Hans Dieter Pearcey]

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:: does, and very little outside Test:: does) and b) there are
a lot of modules named 'Test::$thing' where '$thing' is the thing being tested
(Exception, Warn, File, Timer, just from a quick glance at search.cpan.org),
and 'DNS' fits in with those.

Test::DNS is a perfectly reasonable name.  I don't think it even needs to be
more specific, Sawyer -- the synopsis you gave probably covers 90% of what
people want to do with Net::DNS most of the time.

hdp.

Re: Module naming suggestions : Test::DNS

[Sawyer X]

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 for yours?

 I was going to say something along those lines, but a) his module speaks
 TAP
 (as most of Test:: does, and very little outside Test:: does) and b) there
 are
 a lot of modules named 'Test::$thing' where '$thing' is the thing being
 tested
 (Exception, Warn, File, Timer, just from a quick glance at search.cpan.org
 ),
 and 'DNS' fits in with those.

 Test::DNS is a perfectly reasonable name.  I don't think it even needs to
 be
 more specific, Sawyer -- the synopsis you gave probably covers 90% of what
 people want to do with Net::DNS most of the time.


Yay. Thank you :)

I already put it on Github, and hopefully release ver 0.01 today.


  hdp.

Re: Module naming suggestions : Test::DNS

[Paul LeoNerd Evans]

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 DNS queries, or mocking
the results of such.

Your module doesn't seem to be doing this - perhaps something like
Check::DNS may be a more suitable name for yours?

-- 
Paul LeoNerd Evans

leon...@leonerd.org.uk
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/


signature.asc
Description: PGP signature

Re: Module naming suggestions : Test::DNS

[sawyer x]

Hi Paul, thanks for answering so quicky!

On Sun, Jan 10, 2010 at 8:37 PM, Paul LeoNerd Evans
leon...@leonerd.org.ukwrote:

 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 queries. Same as Test::Ping or the sort.

A major difference between Test::DNS [working title] and most testing
modules is that it is object oriented and not functional. I found some
modules that work OO as well, but don't remember the names right now.


 Such a module would be used to assert on
 the behaviour of code under test.


This isn't really to assert Net::DNS's behavior. Quite the contrary, I rely
on Net::DNS to have correct behavior. I'm testing DNS records, such as
testing ping (Test::Ping), TCP (Test::TCP), file attributes (Test::File) and
so on.


 I would expect, given the name, that Test::DNS would check the behaviour
 of some module, perhaps by asserting it performs DNS queries, or mocking
 the results of such.


This module tries to help you run some DNS tests and check some values, such
as the Test::File module.

Re: Module naming suggestions : Test::DNS

[sawyer x]

Hi.

On Sun, Jan 10, 2010 at 10:43 PM, Dana Hudes dhu...@hudes.org 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 server is okay, I'm checking
the zone attributes, like Test::File checks file attributes.


 In any case, the Check::DNS name does sound more appropriate. IDK about
 Check::Net::DNS. That implies it's Net::DNS you are checking
 Perhaps Check::Server::DNS??


I'm not checking a server, I'm testing DNS records. Moreover, as I point out
previously, I'm using Test::Builder to provide TAP. This, quite honestly,
seems to me like a good candidate for Test:: namespace.

I appreciate the comments and suggestions (and do I consider them) but
honestly, I just wanted some thoughts on Test::DNS vs. Test::DNS::Resolver
(and the sorts). I've already settled in my mind that it's a /^Test::DNS.*/


 I do see a use for TAP. I like the idea of saying
 ok(soa,cpan.org)
 and even
 ok(ns, cpan.org eq [ list of name servers ] )


It's object oriented out of comfort. A functional interface shouldn't be
tricky, but in order to maintain the nameservers (and other persistent
features for DNS and testing behavior), I prefer to use OO instead of
multiple global variables.


 It is more than object oriented. You use OO to extend TAP I guess but its
 really logic programming, a rules system
 I would think we could add this to Nagios or BigBrother.


Quite possibly. We had a system at $work that took us a while to write, it
was over 200 lines. Using Test::DNS, we rewrote the whole thing in about 20
lines, clean and beautiful, in roughly 10 minutes, including all the nasty
edge-cases.

Sawyer.

Re: Module naming advice

[Jeff Lavallee]

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 POD) for the time being, with all the meat under
 that
 namespace (for example, Yahoo::Marketing::AccountService,
 Yahoo::Marketing::Account, etc).  The POD-in-progress for
 Yahoo::Marketing is below.

 Any thoughts/comments/suggestions about the intended namespace would be
 greatly appreciated.
 There is already at least one module in WWW::Yahoo::*. I would
 suggest slotting your modules in at that level as well.

 The WWW:: space is overcrowded and confused.

 The WebService:: namespace was created for modules interfacing with
 web sercices.
 So WebService::Yahoo::* seems like the best home.
 
 I don't think that WebService::Yahoo::* is any clearer than Yahoo::*, so
 my personal preference would be to avoid that if it's new.  If there is
 already a convention for where to find Yahoo interfaces, I would follow
 that, even if that's sub-optimal.
 
 With most of CPAN being accessed by search rather than by category, as
 long as Yahoo is in the module name, it'll be easy enough to find.

The other consideration is that WebService::Yahoo::Marketing::[whatever]
starts to get pretty unwieldy.  The Yahoo:: namespace is already in use
and in the case of Yahoo::Search, it uses web services as well, so it
does seem that a precedent of some sort has been set, which I'm inclined
to follow.


Thanks,

Jeff

Re: Module naming advice

[Tim Bunce]

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
 marketing web services easier.  The modules insulate the user from a lot
 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 meat under that
 namespace (for example, Yahoo::Marketing::AccountService,
 Yahoo::Marketing::Account, etc).  The POD-in-progress for
 Yahoo::Marketing is below.
 
 Any thoughts/comments/suggestions about the intended namespace would be
 greatly appreciated.
 
 There is already at least one module in WWW::Yahoo::*. I would suggest 
 slotting your modules in at that level as well.

The WWW:: space is overcrowded and confused.

The WebService:: namespace was created for modules interfacing with web 
sercices.
So WebService::Yahoo::* seems like the best home.

Tim.

Re: Module naming advice

[David Golden]

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 meat under that
namespace (for example, Yahoo::Marketing::AccountService,
Yahoo::Marketing::Account, etc).  The POD-in-progress for
Yahoo::Marketing is below.

Any thoughts/comments/suggestions about the intended namespace would be
greatly appreciated.
There is already at least one module in WWW::Yahoo::*. I would suggest 
slotting your modules in at that level as well.


The WWW:: space is overcrowded and confused.

The WebService:: namespace was created for modules interfacing with web 
sercices.
So WebService::Yahoo::* seems like the best home.


I don't think that WebService::Yahoo::* is any clearer than Yahoo::*, so 
my personal preference would be to avoid that if it's new.  If there is 
already a convention for where to find Yahoo interfaces, I would follow 
that, even if that's sub-optimal.


With most of CPAN being accessed by search rather than by category, as 
long as Yahoo is in the module name, it'll be easy enough to find.


Regards,
David Golden

Re: Module naming advice

[David Landgren]

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 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 meat under that
namespace (for example, Yahoo::Marketing::AccountService,
Yahoo::Marketing::Account, etc).  The POD-in-progress for
Yahoo::Marketing is below.

Any thoughts/comments/suggestions about the intended namespace would be
greatly appreciated.


There is already at least one module in WWW::Yahoo::*. I would suggest 
slotting your modules in at that level as well.


David

--
hope still, a little resistance always maybe stubborn tiny lights vs. 
clustering darkness forever ok?

Re: Module naming mailing list? Was: Re: New module: FLV file parsing

[Ovid]

--- 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: Module naming mailing list? Was: Re: New module: FLV file parsing

[Eric Wilhelm]

# 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 list, because of 
course the list doesn't want to hear about _foo_) would just be getting 
CC'd on every message and each thread would become its own little 
ad-hoc mailing list.  Sounds like a plan.

--Eric
-- 
If the collapse of the Berlin Wall had taught us anything, it was that
socialism alone was not a sustainable economic model.
--Robert Young
---
http://scratchcomputing.com
---

Re: Module naming mailing list? Was: Re: New module: FLV file parsing

[Austin Schutz]

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 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).
 

Yeah, I don't have an answer for this, and with the level of
importance some give detailed and debated naming, I guess we're stuck with it.

Bring on the nits, let's get splitting.

Austin

Re: Module naming advice

[Alberto Manuel Brandao Simoes]

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' ] qw( foo bar baz );
Regards,
My 5 words...
use aka Name Really::Lond::Module::Name qw(foo bar baz)
--
Alberto Simões - Departamento de Informática - Universidade do Minho
,,__
   ..  ..   / o._)   .---.
  /--'/--\  \-'||...' '.
 /\_/ / |  .'  '..' '-.
   .'\  \__\  __.'.' .'  ì-._
 )\ |  )\ |  _.'
// \\ // \\
   ||_  \\|_  \\_ Perl Monger
   mrf '--' '--'' '--'www.perl-hackers.net

Re: Module naming advice

[A. Pagaltzis]

* 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 _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hacker;

Re: Module naming advice

[David Nicol]

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 much shorter

bar::widget($arg1, $arg2);

How does the contemplated module differ from Package::Alias?

Re: Module naming advice

[Bruce J Keeler]

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::bar::
 }
 
 after which the methods in RLNEB can be referred to
 with the much shorter
 
 bar::widget($arg1, $arg2);
 
 How does the contemplated module differ from Package::Alias?
 
It's similar, but different.  The proposed module does not alias the
package at the level that Package::Alias does, i.e. by messing around
with the stash and globs.  What it does is first require the package,
then insert a constant sub into the caller's package which returns the
long name of the package.  This makes it easier to call class methods,
but does not allow calls of the type you show above.  Thus:

use aka 'Really::Long::Package::Name' = ShortName;
# equiv to   use constant ShortName = Really::Long::Package::Name;
ShortName-new(...);   # works
ShortName::new(...);  # doesn't work
print $ShortName::VERSION; # doesn't work

The advantage of this over the more low-level Package::Alias method is
that objects are blessed into the correct path.  After

package Foo;
*ShortName:: = \*Really::Long::Package::Name::;
my $foo = ShortName-new(...);

$foo would be blessed into Foo::Shortname, or possibly just ShortName
instead of its proper package.

It really is a very useful module; I've been using it for almost a year
and now can't live without it.
-- 
Bruce J Keeler [EMAIL PROTECTED]

RE: Module naming advice

[Orton, Yves]

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 installed into site/lib then whichever one was installed last.


 :-)


Yves

Re: Module naming advice

[Ken Williams]

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 confused with 'Alias.pm'.
Which is my problem with 'alias.'

I think aka doesn't read very well at all.  If I expand use aka 
'Foo::Bar' or use aka 'Foo::Bar' as 'Baz' out in my brain, it'll be 
use also known as Foo::Bar or use also known as 'Foo::Bar' as 
'Baz', which is nonsensical.

It would seem better to use a noun there, perhaps something like use 
alias 'Baz' for 'Foo::Bar', or even just exploit perl's natural 
pairing syntax: use alias 'Foo::Bar' = 'Baz'.

In the case of this module, interface is really everything, of course.  
If I were you I'd really try to nail it before pushing it to release.

 -Ken

Re: Module naming advice

[Kurt Starsinic]

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 subroutines are called as methods.  It exports a subroutine
 into your namespace that is the desired alias for the module.  Having
 used something similar in a large system, I found that having this
 feature became quite addictive.
 
 [ . . . . ]
 
 Is Aliased a good name?  Is aliased better?  Am I overlooking
 anything?

Are you aware of Alias.pm?

- Kurt

Re: Module naming advice

[Ovid]

--- 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 all the time.  This module allows you to
 skip
  that if the subroutines are called as methods.  It exports a
 subroutine
  into your namespace that is the desired alias for the module. 
 Having
  used something similar in a large system, I found that having this
  feature became quite addictive.
  
  [ . . . . ]
  
  Is Aliased a good name?  Is aliased better?  Am I overlooking
  anything?
 
 Are you aware of Alias.pm?

I am aware of that module.  It does something completely different from
mine, so I'm not worried about duplicating functionality.  However, I
do realize the name can cause some confusion.  I welcome other
suggestions.  I had briefly considered module.pm or class.pm, but I
envisioned howls of protests:

  use class Really::Long::Class::Name;
  my $o = Name-new;

However, I do think it's more clear.

Cheers,
Ovid

=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

RE: Module naming advice

[Hugh S. Myers]

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,
 
 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.
 
 SYNOPSIS:
 
   use Aliased 'Really::Long::Module::Name';
   use Aliased 'Really::Long::Conflicting::Module::Name' as MName;
   use Aliased 'Another::Silly::Example' import = [qw/foo bar baz/];
 
   # my $name = Really::Long::Module::Name-new;
   my $name = Name-new;
 
   # my $mname = Really::Long::Conflicting::Module::Name-new
   my $mname = MName-new;
 
   # my $wibble = Another::Silly::Example-constructor.
   my $wibble = Example-constructor;
 
 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 subroutines are called as methods.  It exports a subroutine
 into your namespace that is the desired alias for the module.  Having
 used something similar in a large system, I found that having this
 feature became quite addictive.
 
 Since this affects compile-time behavior, it seemed more appropriate to
 think of this as a pragma and have use aliased but I know that some
 frown on that (of course, Ingy released only and I didn't hear any
 complaints.)
 
 Is Aliased a good name?  Is aliased better?  Am I overlooking
 anything?
 
 Cheers,
 Ovid
 
 =
 Silence is Evil
 http://users.easystreet.com/ovid/philosophy/decency.html
 Ovid   http://www.perlmonks.org/index.pl?node_id=17000
 Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

Re: Module naming advice

[Bruce J Keeler]

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.  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 very useful.  Would certainly get
my vote.

-- 
Bruce J Keeler [EMAIL PROTECTED]

Re: Module naming advice

[David Wheeler]

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 very useful.  Would certainly get
my vote.
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. Here are some 
other options:

* alias (too close to Aliased?)
* nickname
* moniker
* pseudonym
* aka
* anonym
* handle (not a file handle, though, might be confusing)
* label
* term
* shortcut
I kind of like aka, actually. But nickname, moniker, and shortcut are 
all good, too.

Just my $0.02.
Regards,
David

Re: Module naming advice

[Brad Lhotsky]

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 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 very useful.  Would certainly get
 my vote.
 
 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. Here are some 
 other options:
 
 * alias (too close to Aliased?)
 * nickname
 * moniker
 * pseudonym
 * aka
 * anonym
 * handle (not a file handle, though, might be confusing)
 * label
 * term
 * shortcut
 
 I kind of like aka, actually. But nickname, moniker, and shortcut are 
 all good, too.
 
 Just my $0.02.
 
 Regards,
 
 David
 

Re: Module naming advice

[Randy W. Sims]

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 lightweight beast, and very useful.  Would certainly get
my vote.

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. Here are some other 
options:

* alias (too close to Aliased?)
* nickname
* moniker
* pseudonym
* aka
* anonym
* handle (not a file handle, though, might be confusing)
* label
* term
* shortcut
I kind of like aka, actually. But nickname, moniker, and shortcut are 
all good, too.
There is Package::Alias[1]. Does the same thing, but I haven't used it.
I like the idea of it being a pragma; 'aka' seems kinda perlish.
It'd be nice if this was supported in perl, so it would be possible to 
alias entire namespaces

use aka 'Apache2::Apache::' as 'Apache::';  # ;-)
Which would all all modules in the first namespace to be addressed as if 
they were in the second, including munging %INC so it does the right thing.

1. http://search.cpan.org/dist/Package-Alias/

Re: Module naming advice

[Eric Wilhelm]

# 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 than
loading a class
snip
I kind of like aka, actually. 

Me too, except for how it reads in the 'use' statement.

  use aka 'Really::Long::Module::Name';
  use aka 'Really::Long::Conflicting::Module::Name' as MName;
  use aka 'Another::Silly::Example' import = [qw/foo bar baz/];

That looks like 'use' is Also Known As Really::Long::Module::Name, 
when what we really mean (and therefore want to say) is more like:

  use Really::Long::Module::Name aka Name;

Of course, the 'use' mechanism isn't able to do this at present (that 
is:  pragmas don't even work this way), so maybe one of the other 
names is in order.  'alias' as an adverb doesn't work in that order 
either, but works as a verb, which is sort-of where you're stuck 
unless you build this functionality into the use() function.

Of course, alias as a verb isn't in the dictionary, we geeks just read 
it that way because of the bash function.  It any case, it seems that 
'alias.pm' might get confused with 'Alias.pm'.

Now I'm strapped to come-up with a verb which doesn't sound so 
nounish.  Consulting the resident linguist (aka wife) results in 
'dub' (as in 'I dub thee'), so I'll throw that out as a suggestion.

  use dub 'Really::Long::Module::Name' as 'Name';

That also seems to work well as an alternative to the use function 
rather than a module or pragma (yeah, perl needs more functions in 
the core.)

  dub Long::Name;
  dub Long::Name as Name;

As for the interface, I really like the 'as' part, but the 'import = 
[qw(stuff)]' seems clunky.  Is there a reason that this syntax can't 
work:

  use dub 'Long::Name' qw(foo bar baz);
  use dub 'Long::Name' as 'Name' qw(foo bar baz);

--Eric
-- 
Chess is a foolish expedient for making idle people believe 
they are doing something very clever when they are only wasting 
their time.
--George Bernard Shaw

Re: Module naming advice

[Ovid]

--- 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'.

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?


 As for the interface, I really like the 'as' part, but the 'import =
 [qw(stuff)]' seems clunky.  Is there a reason that this syntax can't 
 work:
 
   use dub 'Long::Name' qw(foo bar baz);
   use dub 'Long::Name' as 'Name' qw(foo bar baz);

That fails because if the real module accepts  'as' in the import list,
I have no way to disambiguate things.

As a convenience, if you only  have a single import item, you can do
this:

use aka 'Really::Long::Module::Name' import = 'thingy';

Cheers,
Ovid

=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

Re: Module naming advice

[Bruce J Keeler]

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 long name of the module.  All this is really good for is
calling class methods.

use Aliased 'Long::Module::Name' as 'Name';
# i.e.   use constant Name = 'Long::Module::Name';

Name-new();  # Works
print $Name::VERSION; # Doesn't work.

Package::Alias sounds like it messes with the stash, something like

$::{'Name::'} = $::{'Long::Module::Name::'}

if I recall the syntax correctly.  The downside to this approach is that
objects created via an aliased package name will be blessed into the
aliased package name rather than the original one, which could confuse
things.

 I like the idea of it being a pragma; 'aka' seems kinda perlish.
 
 It'd be nice if this was supported in perl, so it would be possible to 
 alias entire namespaces
 
 use aka 'Apache2::Apache::' as 'Apache::';  # ;-)
 
 Which would all all modules in the first namespace to be addressed as if 
 they were in the second, including munging %INC so it does the right thing.

This is a completely different problem, requiring a different solution.

For the record, I still like the name 'aliased', partly because I'm used
to it.
-- 
Bruce J Keeler [EMAIL PROTECTED]

Re: Module naming advice

[Jenda Krynicky]

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 really like the 'as' part, but the 'import
  = [qw(stuff)]' seems clunky.  Is there a reason that this syntax
  can't work:
  
use dub 'Long::Name' qw(foo bar baz);
use dub 'Long::Name' as 'Name' qw(foo bar baz);
 
 That fails because if the real module accepts  'as' in the import
 list, I have no way to disambiguate things.
 
 As a convenience, if you only  have a single import item, you can do
 this:
 
 use aka 'Really::Long::Module::Name' import = 'thingy';

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);

Eric Wilhelm [EMAIL PROTECTED] suggested:
 Now I'm strapped to come-up with a verb which doesn't sound so 
 nounish.  Consulting the resident linguist (aka wife) results in 
 'dub' (as in 'I dub thee'), so I'll throw that out as a suggestion.
 
   use dub 'Really::Long::Module::Name' as 'Name';

Sorry, that would not work for me. I found it in the dictionary, but I've never 
heard/seen it. And I doubt other foreigners did either, may be mistaken.

Actually, what about renamed?

use renamed 'Really::Long::Module::Name as MName' qw(foo bar baz);

Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed 
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery

Re: Module naming advice

[Sam Vilain]

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 reads very well:
 use module 'Foo::Bar' as 'Bar';
 use package 'Foo::Bar' as 'Bar';
And this does not read as well (at least, in English):
 use aka 'Foo::Bar' as 'Bar';
My suggestion;
 use aliasing to 'Bar', 'Foo::Bar';
With the upside that aliasing also clearly states what the module
does.
--
Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

Re: Module naming advice

[Ovid]

--- 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
only for OO modules.
 
 And this does not read as well (at least, in English):
 
   use aka 'Foo::Bar' as 'Bar';

Yeah, I really don't like it.

 My suggestion;
 
   use aliasing to 'Bar', 'Foo::Bar';
 
 With the upside that aliasing also clearly states what the module
 does.

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, but the one that reads the most naturally class, seems to
not be favored by people.

Cheers,
Ovid

=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid   http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl  http://users.easystreet.com/ovid/cgi_course/

Re: Module naming advice

[Eric Wilhelm]

# 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 have a space in a module name, 
so your suggestion gives Ovid an easy ($new, $old) = 
split(/\s+as\s+/, $arg); to work-out which as is which.

Eric Wilhelm [EMAIL PROTECTED] suggested:
 'dub' (as in 'I dub thee'), so I'll throw that out as a
 suggestion.
Sorry, that would not work for me. I found it in the dictionary, but
 I've never heard/seen it. And I doubt other foreigners did either,
 may be mistaken.

Hmm.  Never seen/heard/read anything about knights/knighthood?  What 
about 'dubya'?  Have you heard of him? (so-named for his tendency to 
assign nicknames to members of his cabinet, foreign ministers, etc.)

Oh well.  Dreams and kittens...

--Eric
-- 
Matter will be damaged in direct proportion to its value.
--Murphy's Constant

Re: Module naming advice

[Scott W Gifford]

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, but the one that reads the most naturally class, seems to
 not be favored by people.

What about something like 'shortname':

  use shortname Really::Long::Class::Name;
  use shortname CName = Really::Long::Class::Name;

or 

  use shortname CName for Really::Long::Class::Name;

It's confusing to have unrelated modules called Alias and aliasing.

ScottG.