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

Module Naming & Relevancy

[Brian Erickson]

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

Re: Noob questions on module naming and repo organization

[Leam Hall]

On 6/22/21 8:59 PM, Leam Hall wrote:

If you assume I know nothing, you'll be pretty close to right.  :)

I'm working on an application that collates text files into a "book". It will 
also provide grade level reports and alternate output formats. I'm looking for wisdom on 
how to organize the Perl code and how to set up the git repo to reasonably replicate the 
namespaces. For reference, the current code is:

 https://github.com/LeamHall/bookbot

The namespace "Book::Collate" has been suggested. In reading the perlmod* documents, my 
plan might be an app. Unless I make the "Book::Collate" modules and then write an app 
that uses them. As an app, usage might be:

 my_app -f  --report --word-list --thumbs --latex

Assuming the a book repository like:

 my_app_repo/
   my_app.conf
     /sections    // book chapters, or sections
     /images
     /output

my_app would make a ~/reports directory (or other, as specified in the 
config_file) and write grade level reports (by section, and by grade) to that 
directory. Because of the --word-list it would also write a file that listed 
words that were frequently used. The --thumbs would make it go into ~/images 
and make a thumbnail image for any image file in the directory. (Useful for web 
pages and listing books on Amazon). It would produce LaTeX and text (default) 
output in ~/output.

So, write modules like this:

 Book::Collate
 Book::Collate::Report
 Book::Collate::Thumbnails
 Book::Collate::LaTeX
 Book::Collage::WordList

and then a app that pulls it all together? Should all the above be one 
repository, or one per namespace? They are tightly coupled, so you couldn't use 
Book::Collate::Report without Book::Collate.

I'd appreciate your help getting this right.

Thanks!



I've gotten some good advice in private e-mail, so the plan is being refined. 
I'm also studying the perlmod* docs for guidance. So far the solution seems to 
be:

Modules:
  Book::Collate
  Book::Collate::Report
  Book::Collate::Thumbnails
  Book::Collate::LaTeX
  Book::Collage::WordList

Application:
  App::BookBot// Or something like that.

I've also gotten a copy of Cross' "Data Munging With Perl"; good stuff! It's 
helping me refine my thought processes. I do need to figure out the data structures, 
since the modules will each use them, and someone might not have a module installed.

Leam

--
Systems Programmer (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well  (github.com/LeamHall)

Noob questions on module naming and repo organization

[Leam Hall]

If you assume I know nothing, you'll be pretty close to right.  :)

I'm working on an application that collates text files into a "book". It will 
also provide grade level reports and alternate output formats. I'm looking for wisdom on 
how to organize the Perl code and how to set up the git repo to reasonably replicate the 
namespaces. For reference, the current code is:

https://github.com/LeamHall/bookbot

The namespace "Book::Collate" has been suggested. In reading the perlmod* documents, my 
plan might be an app. Unless I make the "Book::Collate" modules and then write an app 
that uses them. As an app, usage might be:

my_app -f  --report --word-list --thumbs --latex

Assuming the a book repository like:

my_app_repo/
my_app.conf
/sections   // book chapters, or sections
/images
/output

my_app would make a ~/reports directory (or other, as specified in the 
config_file) and write grade level reports (by section, and by grade) to that 
directory. Because of the --word-list it would also write a file that listed 
words that were frequently used. The --thumbs would make it go into ~/images 
and make a thumbnail image for any image file in the directory. (Useful for web 
pages and listing books on Amazon). It would produce LaTeX and text (default) 
output in ~/output.

So, write modules like this:

Book::Collate   
Book::Collate::Report
Book::Collate::Thumbnails
Book::Collate::LaTeX
Book::Collage::WordList

and then a app that pulls it all together? Should all the above be one 
repository, or one per namespace? They are tightly coupled, so you couldn't use 
Book::Collate::Report without Book::Collate.

I'd appreciate your help getting this right.

Thanks!

Leam



--
Systems Programmer (reuel.net/resume)
Scribe: The Domici War (domiciwar.net)
General Ne'er-do-well  (github.com/LeamHall)

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

Module naming advice, please.

[Rory McKinley]

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

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
>

Module naming - exposing Win API function ShellExecute

[Timothy Madden]

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
>

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

[Diab Jerius]

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

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

[BC]

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

--
---[ 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: Checking module naming

[David Mertens]

Sorry for a delayed answer, but here are my thoughts. It looks like you've
published your module using the proposed naming. Your choice was a good
one, in my opinion. Glad to see this hit CPAN!

David

On Fri, Oct 16, 2015 at 8:46 PM,  wrote:

> Heyas everyone,
>
> I'm in the process of organising to have my very first contribution to CPAN
> uploaded and see that it may be prudent to ask for feedback on the names I
> currently have, especially as it is claiming a top-level name!
>
> I'm very open to suggestions, though I do hope these are okay!
>
> 
>
> Currently, I have the following modules:
>
> OpenHMD
>
> Utilising Inline::C, this module provides a binding to the
> OpenHMD C
> library (http://openhmd.net/), intended to be a very thin
> wrapper
> (i.e. behave as closely as possible to the C library).
>
> OpenHMD::Simple
>
> Utilising the OpenHMD module (above), this provides a
> *very* simple
> OO interface to OpenHMD, letting you use the library with
> very few
> methods (just 3) in the simplest case of a known device
> index,
> such as the default device, 0).
>
>  my $openhmd = OpenHMD::Simple->new(0);
>  while (1) {
>  $openhmd->update;
>  my $state = $openhmd->state;
>  }
>
> In the near future I will also be creating:
>
> OpenHMD::Context
> OpenHMD::Device
>
> These are the fully fleshed out OO interfaces, providing
> individual
> methods for everything and allowing proper use of the
> library in a OO
> manner. These would utilise the OpenHMD module above and
> OpenHMD::Simple would be migrated to using these instead
> of OpenHMD
> directly.
>
> In the more distant future, I'd like to make:
>
> OpenHMD::Backend::Inline
> OpenHMD::Backend::XS
>
> I'd like to convert OpenHMD to be a "frontend" module that
> allows the
> use of multiple possible backends (Inline, XS, ... PP?).
>
> 
>
> I'm not sure if it matters at all, but I checked with the lead OpenHMD
> developers and they have given their blessing for me to use the 'OpenHMD'
> namespace (they have been very supportive of my efforts, even regarding me
> as part
> of the team). They can be contacted in #openhmd on freenode to confirm.
>
> Thanks for your time, I hope these names are acceptable and that you have
> a nice day!
>
> Regards,
> CandyAngel
>
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

Checking module naming

[candyangel]

Heyas everyone,

I'm in the process of organising to have my very first contribution to CPAN
uploaded and see that it may be prudent to ask for feedback on the names I
currently have, especially as it is claiming a top-level name!

I'm very open to suggestions, though I do hope these are okay!



Currently, I have the following modules:

OpenHMD

Utilising Inline::C, this module provides a binding to the 
OpenHMD C
library (http://openhmd.net/), intended to be a very thin 
wrapper
(i.e. behave as closely as possible to the C library).

OpenHMD::Simple

Utilising the OpenHMD module (above), this provides a *very* 
simple
OO interface to OpenHMD, letting you use the library with very 
few
methods (just 3) in the simplest case of a known device index,
such as the default device, 0).

 my $openhmd = OpenHMD::Simple->new(0);
 while (1) {
 $openhmd->update;
 my $state = $openhmd->state;
 }

In the near future I will also be creating:

OpenHMD::Context
OpenHMD::Device

These are the fully fleshed out OO interfaces, providing 
individual
methods for everything and allowing proper use of the library 
in a OO
manner. These would utilise the OpenHMD module above and
OpenHMD::Simple would be migrated to using these instead of 
OpenHMD
directly.

In the more distant future, I'd like to make:

OpenHMD::Backend::Inline
OpenHMD::Backend::XS

I'd like to convert OpenHMD to be a "frontend" module that 
allows the
use of multiple possible backends (Inline, XS, ... PP?).



I'm not sure if it matters at all, but I checked with the lead OpenHMD
developers and they have given their blessing for me to use the 'OpenHMD'
namespace (they have been very supportive of my efforts, even  
regarding me as part

of the team). They can be contacted in #openhmd on freenode to confirm.

Thanks for your time, I hope these names are acceptable and that you  
have a nice day!


Regards,
CandyAngel

Re: (FYI)...Module naming collision Or mirage?

[Linda W]

On 2013-11-12 23:54, Aldo Calpini wrote:

Ingy is the original author of the first version of Inline:

http://search.cpan.org/~ingy/Inline-0.44/

Sisyphus is the current maintainer.

Ingy already has first come since 2002...



Um... but Sisyphus says it's not a real module -- it is never installed.

How is this different than domain sitting?

Re: (FYI)...Module naming collision Or mirage?

[Aldo Calpini]

On 11/13/2013 10:04 AM, Linda W wrote:

Um... but Sisyphus says it's not a real module -- it is never installed.

How is this different than domain sitting?


you already got a reply to this from Leon:

 PAUSE automatically indexes everything it can find, unless you tell 
it otherwise


indexed modules belong to the author on a first come basis. you can 
call it domain sitting if you want, but this is how CPAN works, and has 
always worked.


Sisyphus already said he's going to rename the module, and I'm confident 
the namespace authority will be sorted out via comaint. case closed, 
right? :-)


cheers,
Aldo

Re: (FYI)...Module naming collision Or mirage?

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

 Sisyphus says it's not a real module -- it is never
 installed.

There's no such thing as a real or unreal module. Either a package name
is indexed, and then the PAUSE permissions model applies, or it's not
indexed, and then there are no PAUSE permissions. Whether something
gets installed or not does not enter into it. We have established that
Math::Simple is indexed, and currently resolves to Inline; deal with
it accordingly.

$ cpanm Math::Simple
-- Working on Math::Simple
Fetching http://www.cpan.org/authors/id/S/SI/SISYPHUS/Inline-0.53.tar.gz 
... OK
Configuring Inline-0.53 ... OK

 How is this different than domain sitting?

Because of the intent. You very well already know that the indexing of
Math::Simple was an accident. In general, the permissions model (of
which first-come is only a part), combined with the policies for
conflict resolution, framed in the Internet culture of working code and
cooperation worked very well in the last decades. AFAIK no one ever
maliciously squatted.


signature.asc
Description: PGP signature

Re: (FYI)...Module naming collision Or mirage?

[Linda A. Walsh]

On 2013-11-13 01:34, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:

Because of the intent. You very well already know that the indexing of
Math::Simple was an accident.

Right... and as soon as Sysyphus found out it was index, he had no problem
letting it go to be used.



 In general, the permissions model (of
which first-come is only a part), combined with the policies for
conflict resolution, framed in the Internet culture of working code and
cooperation worked very well in the last decades. AFAIK no one ever
maliciously squatted.
  


The name has been dormant and unused for 11 years, yet it has
been reserved? If Inge wanted to use it for anything at any
time, he could have done so as easily as asking.  Now when I
investigate the usage and availability, I'm told it is reserved
by someone who has not had minimal interest in it for 11 years. 


I'm not strongly wedded to owning it -- if Inge wants to take my
5 functions and export them from Math::Simple, that's fine w/me...
They are very trivial (logb(base,x) log2(x) log10(x) min(x,[list]),
max(x,[list]).

But you did say this discussion was framed in the culture of working
code. The name has been reserved for 11 years w/o working code.  I
just brought up the issue because I ran into it running a report in
cpan recently.  It's more of a bother for me to release them than
have him do it if that's what he's into, but if he's not going
to use the name ...

I'm not trying to be difficult, but I find the idea that someone would
have an unused, reserved name for 11 years w/no code behind it,
but who's said to own such a bit un-perlish.

If he wanted it, why didn't he ask for it or use it?

Seems odd to have a reservation for such for 11 years and not use it.

Re: (FYI)...Module naming collision Or mirage?

[David Cantrell]

On Wed, Nov 13, 2013 at 02:29:07AM -0800, Linda A. Walsh wrote:

 The name has been dormant and unused for 11 years, yet it has
 been reserved?

This is how first-come first-served works.  He came first, so he got
dibs on the name. That he appears to have come to it by accident is
unfortunate, but irrelevant.

 If Inge wanted to use it for anything at any
 time, he could have done so as easily as asking.

For people to have to request namespaces in advance would impose an
intolerable burden on the PAUSE maintenance crew, a small burden on
authors, and lead to longer times between releases. Do you seriously
think that it would be a good idea for me to have had to *ask* for all
the module names in Number-Phone? There are 251 of them. And most of
them are auto-generated so unless I bother to look at what's there *I
don't know what they are*. Or there's Devel-CheckOS (58 modules), or
DBIx-Class (154 modules).

Now consider that there are 80-ish uploads to the CPAN every day, and
you'll realise how manual requests and approvals are not practical.

   Now when I
 investigate the usage and availability, I'm told it is reserved
 by someone who has not had minimal interest in it for 11 years. 

I'm sure that if you ask nicely either INGY or the PAUSE gods will fix
things. SISYPHUS has already said that he'll do what he can.

 But you did say this discussion was framed in the culture of working
 code. The name has been reserved for 11 years w/o working code.

Don't confuse individual instances of code with a culture of working
code.

 I'm not trying to be difficult, but I find the idea that someone would
 have an unused, reserved name for 11 years w/no code behind it,
 but who's said to own such a bit un-perlish.
 
 If he wanted it, why didn't he ask for it or use it?
 
 Seems odd to have a reservation for such for 11 years and not use it.

It has already been explained to you that it was reserved by the
indexer, which thought it was working code. Now please, stop whining.

-- 
David Cantrell | semi-evolved ape-thing

You can't spell AWESOME without ME!

Re: (FYI)...Module naming collision Or mirage?

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

 The name has been dormant and unused for 11 years, yet it has
 been reserved?

Not quite, the module was uploaded and indexed, and was in use as
example code. This is *not* a reservation. Please notice the *lack of
intent* here for Math::Simple to be indexed.

 If Inge wanted to use it for anything at any
 time, he could have done so as easily as asking.

Names are indexed by uploading, not by asking.

 Now when I
 investigate the usage and availability, I'm told it is reserved
 by someone who has not had minimal interest in it for 11 years.

So what? It is perfectly possible for you to take over the name for a
different purpose.

 But you did say this discussion was framed in the culture of working
 code. The name has been reserved for 11 years w/o working code.

That's not what I meant.

 It's more of a bother for me

If you have no patience to have other people sort out PAUSE permissions
for you, then you are free to occupy a different unused name.

I advise you to wait it out and bridge the time by publishing the code
on Github or similar, and posting to http://prepan.org,
http://perlmonks.org/?node=Meditations and this list in order to get
feedback on it. Judging by your latest CPAN release, you very much
would benefit from feedback.


signature.asc
Description: PGP signature

Re: (FYI)...Module naming collision Or mirage?

[Linda W]

On 2013-11-13 07:39, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:

 Judging by your latest CPAN release, you very much
would benefit from feedback.
  


   I'm sorry, I'm a perfectionist.  If I see something wrong, I don't 
necessarily
hide things like most people.  The quality of P hasn't been a major 
problem.  You
can check the bug reports and find that there as a spate of them a month 
ago when
some people first looked at it, and all but a few opinion doc bugs 
have been fixed. 

   Almost half were critical bugs, like extra space after period... 
Real serious
quality issues!  Some were real and you can see how I marked them -- I 
marked
the serious and important ones such, and tried to handle the ones lower 
than normal
delicately. 

People on here would do well to read how I handled the bug reports.  
It's interesting how
people out in the world think that releasing early and releasing often 
-- a motto of open
source, think that is some reflection on quality.  I get to a point 
where my stuff is better
than 90+% of the stuff out there because I am willing to make mistakes 
and fix them and

usually do so faster than most.

What you are intimating as a defect, is my strength.  If you haven't 
noticed, I tend
not to give up easily.That bothers people.  As for test failures -- 
they've all come from
3 people. -- with over 60% coming from 1 person.  The other two are on 
Win2k or winXP --
not sure which, and while I will get to that, if possible, Windows is 
it's own special case.


The other testor who owns 60% of the failures tests on tons of different 
versions but
in a way that makes it hard to invoke the perl version he is using last 
attempt was
using $Config of the running perl to determine the executable to use -- 
suggested
by the tester's wiki but I didn't get the args right.  Maybe I'll 
someday have such a test

setup at my disposal, but until then...

I'd say the record of my 1st release from 1.0.12-1.0.20 was fairly 
good.  The PASS ratio of 'mem.pm' is even better, showing 61/61 passes 
in the lst 3 releases.  All of the failures since
the second release have had to do with the test harness.  Do you think I 
feel responsible for
those?  I don't.  They happen because having worked in QA for years 
doing test automation,
they don't act like any test harness I'm used to.  Unfamiliarity isn't a 
big issue.  I'm unfamiliar with most knowledge in the world.  Anyone 
thinks differently hasn't been around much.


So the wonderful writeup I got of P, made me quite happy.  It means I'm 
doing something
right -- i.e. if no one took the time to say anything, I wouldn't know 
they cared.

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: (FYI)...Module naming collision Or mirage?

[Linda A. Walsh]

On 2013-11-12 14:52, Leon Timmermans wrote:
On Tue, Nov 12, 2013 at 11:43 PM, Linda A. Walsh 
perl-didd...@tlinx.org mailto:perl-didd...@tlinx.org wrote:


I've seen double listings (look at 'P', there's a really old
listing for someone
else who has a reference to P in their directory, but not as a
module.


Have a try at uploading your Math::Simple if you like. It may
succeed and it does then that's fine - it's not going to get
clobbered by my Math::Simple unless someone actually builds and
installs the demo. (And, in the next release of Inline, I can
rename the demo module to something like Inline::ModDemo, where it
shouldn't cause any grief to anyone in the future.)

 
It will fail unless Ingy gives you permission (he has first-come on 
that namespace).


??? Who is Ingy and how does he come into the picture?

I.e. if I just cleared the namespace ... someone else gets first come 
on it?

How does that make sense?

Re: (FYI)...Module naming collision Or mirage?

[Karen Etheridge]

On Tue, Nov 12, 2013 at 09:43:54PM -0800, Linda A. Walsh wrote:
   It will fail unless Ingy gives you permission (he has first-come
 on that namespace).
 
 ??? Who is Ingy and how does he come into the picture?

https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=mepause99_peek_perms_query=Math%3A%3ASimplepause99_peek_perms_sub=Submit

Re: (FYI)...Module naming collision Or mirage?

[Aldo Calpini]

On 11/13/2013 06:43 AM, Linda A. Walsh wrote:

??? Who is Ingy and how does he come into the picture?


Ingy is the original author of the first version of Inline:

http://search.cpan.org/~ingy/Inline-0.44/

Sisyphus is the current maintainer.

I.e. if I just cleared the namespace ... someone else gets first 
come on it?

How does that make sense?


Ingy already has first come since 2002...


cheers,
Aldo

Module naming collision Or mirage?

[Linda A. Walsh]

When I look up Math::Simple, I find a module under
Math::Simple::Simple.pm
which seems to hit the index as Math::Simple

So if I wanted to add Math::Simple.pm,  How would it show up
and/or how would they be differentiated?

It's also the case that Math::Simple::Simple.pm looks like it is
a demo case for Inline (I.e, it's not a real perl module, but an
example using Inline).  Should it even be listed as a module?

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

Module naming and a couple other questions

[Joshua Megerman]

I originally sent this to modu...@perl.org, but got no responses. I was
pointed here and am reposting them with a few tweaks.  Any advice greatly
appreciated!

I'm a new member of PAUSE, looking to upload my first module.  I ask for
some advice from those who have more experience than I, as I'd like to do
this the right way the first time :)

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.

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, but it seems that there's little chance of polluting the general
namespace, given that the existing WMI modules don't use it nor do they
operate that way.  At some point I may add an OO interface, but that's not
an immediate concern of mine.  Do you have any strong objections to the
default export?

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?

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.  Suggestions/pointers would be
appreciated.

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.  Again, I don't know how to
handle that requirement via CPAN - if you can point me to a good reference
on how to do that, I'd appreciate that as well.

Thanks, and I look forward to your response.
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

RFC: Module naming: User::Credentials::Provider::DBI

[David Oswald]

I have developed a module that has sort of evolved with me through
several projects.  On the most recent evolution it has reached a point
that I think it might be generally useful as a CPAN module.

The module models a user login with a DBIx::Connector back-end.

Logins authenticate using both passphrase, and optionally per-user, IP
whitelists.  Passphrases are always required.  Individual users may be
required to also match an IP whitelist set up for that user.
Different users may have different whitelists, or no whitelist
requirement at all.  Passphrases are salted with a 512 bit random salt
(different for each user), and hashed with a SHA2-512 digest.

User credentials include userid, salt, passphrase hash, email, user
name, optional IP whitelists, optional user roles.

Public API methods include:

my $user_obj = new( $dbix_connector, $userid )
my $user_id  = $user-add_user(
   {
   password = $password,# Passphrase will get a 512 bit
random salt, and will be digested via SHA-512.
   ip_req   = $bool_ip_req,   # Optional Boolean: Is there an
IP whitelist requirement for this user?
   ips  = [ '192.168.0.100', '201.202.100.5' ], #
Optional aref of whitelisted ip's.
   username = $full_name,  # User's full name (optional field)
   email= $email,   # User's email (optional field)
   }
);
my $userid  = $user-userid;
my $validated   = $user-validated;# Test whether user has
been validated.
my $invalidated = $user-validated(0);# Invalidate user.
my $is_valid= $user-validate_user( $pass, $opt_ips_aref );
my $info_href= $user-load_user; # Load a hashref
containing userid, username, email, other credentials excluding
pass-hashes.
my $valid_ips_aref   = $user-fetch_valid_ips; # Return aref of
whitelist IPs for user (if applicable).
my $user_exists = $user-exists_user;
my $success = $user-delete_user;
my $del_count   = $user-delete_ips( [ @ips ] );  # Delete one or more
whitelist IP's (if applicable).
my $add_count   = $user-add_ips( [ @ips ] );# Add one or more
whitelist IP's (if applicable).
my $new_email   = $user-update_email( 'new@email.address' );
my $new_name= $user-update_username( 'Cool New User Name' );
my $success  = $user-update_password( 'Old Pass', 'New Pass' );
my $cans_aref = $user-fetch_roles;
my $success  = $user-add_roles( [ @new_roles ] );
my $success = $user-delete_roles( [ @roles ] );
my $can_do= $user-can_role( [ @roles_to_test ] );


Passphrases for new users are salted with a 512 bit random salt using
a cryptographically strong random number generator, and digested using
SHA2-512 (Authen::Passphrase::SaltedSHA512).  Salt and Hash are stored
in a db along with userid, username, email, optional boolean setting
whether or not IP whitelisting is to be used in validation.

A second table associates valid IP's with userid's, and is used if the
ip_req field is true in the users table.

A third table handles user roles.  A user might have multiple roles.
This facilitates providing user access to certain portions of an
application, while denying (or rendering differently) for other
portions of an application depending on what roles the user can
do/access.

My most recent use-case was on a Mojolicious project, where it
integrated well with Mojolicious::Plugin::Authentication and
Mojolicious::Plugin::Authorization.  But I think it's general enough
to fit into other applications and other frameworks.

I've used this in several projects, and am finally getting around to
making it database agnostic, though it does need to be handed a
DBIx::Connector object to use.  The DBIx::Connector requirement is
hard wired; it uses DBIx::Connector's nice (and reliable) 'fixup',
'run' and 'txn' features for safe atomic commits in a preforking (aka
Hypnotoad server) environment.  The SQL resides in a helper module so
that all queries can be seen and if necessary edited in one compact
location.  I'll be converting its test suite to a BUILD_REQUIRES of
DBD::SQLite for testing purposes prior to packaging it up as a
distribution.

Now for the questions:

Will this be general enough to be useful on CPAN?

What would you call it?  (One individual suggested
User::Credentials::Provider::DBI.  In my own personal use I've been
calling it DBIx::Connector::Model::User.)

What have you been using?

While there is a design goal of keeping it as simple as practical,
what features seem to be missing?


Dave


-- 

David Oswald
daosw...@gmail.com

Module naming: postifx/dovecot/MySQL configuration

[Avi Greenbury]

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/

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

Module Naming for Perl Reference Object Lookup

[mark]

Hello people of module-authors!

I have been working on a module which will allow one to do some 
relatively advanced storage and lookup mechanisms

on pure Perl object references.

The features are as follows:

1) Use perl objects as keys.
2) You may choose whether the database will retain a strong or
weak reference to either the key or the value
3) You may store a single value under multiple keys; keys may be of 
mixed type
4) Reference keys and objects may optionally be deleted when their 
referrant objects are destroyed
5) Store multiple value objects under 'tags' or 'attributes', these tags 
themselves may be either

strings or references
6) Multiple deletion options, delete all keys/attributes
by a value, delete a value by any given key, delete
any values for a given attribute, delete an attribute lookup, 
dissociate an attribute from

a value
7) Elegant debugging/dumping information, showing a lower level view of 
the lookup table
8) Uniform API with two currently implemented backends (one is my XS 
code, other uses Variable::Magic)
9) Unlike Hash::Util::FieldHash, this module will work with perl 5.8.8 
(the version used in EL5-based distributions)
10) Decent speed, using an intel xeon E5520 CPU, i was able to acheive 
200k store/sec for string keys, 150k store/sec for object keys, and 50k 
store/sec for attribute lookups. At best this is still a good 6-7 times 
slower than a normal perl hash, but is still

acceptable.

An example usage module (poco-keepalive) is available here:
https://github.com/mnunberg/Hash-Registry/blob/master/examples/poco-component-keepalive.pm

Implementation details ae here:
https://github.com/mnunberg/Hash-Registry/blob/master/Guts.pod

Basic API interface is here:
https://github.com/mnunberg/Hash-Registry/blob/master/api_list.txt

and of course, you should be able to determine where the rest of the 
stuff is, if you wish to look into it a bit more.


Anyway, the question I wish to ask is in respect to naming this module;
I have had several ideas for naming this, all which are unacceptable;
The current name (Hash::Registry) was randomly chosen when this project 
was still just hoping to be some kind of tied hash


Another idea was Data::Registry or Object::Registry, but this makes the 
module sound like it's dealing with actual 'data'
rather than perl references, while the emphasis is very much on opaque 
perl references (such as globrefs, etc.) rather than even trying to make 
an attempt to deal with actual 'data' (that is, serialization, 
inspection of object methods etc. etc.).


Another name that came up was Data::RefDB, which is a bit inelegant, and 
sadly, anything with the name 'DB' in it seems to imply something of an 
RDBMS or at least something with serializing and persistent storage 
(while my module wants nothing to do with either).


The name that's been sticking with me for a while has been 'Prod', or 
Perl Reference Object Database. But, it's a top-level namespace and 
someone commented that it gives the impression of having something to do 
with POD, so I'm quite lost.


Another thing to note is that I will probably want to publish a few more 
modules under this namespace; at least one comes to mind, and that is 
::Trigger, which will provide a common PP and XS interface for 
performing various actions on Cfree magic, such as calling a CV, 
deleting a hash entry or array element, or even calling a C function 
(the XS implementation already provides the API and I just need to tidy 
it up a bit), and would be a far higher performing substitute for common 
cases of DESTROY


__END__

Synopsis:

=head1 SYNOPSIS

my $table = Hash::Registry-new();

Store a value under a simple string key, maintain the value as a weak 
reference.

The string key will be deleted when the value is destroyed:

$table-store(key, $object);

Store C$object under a second index (C$fh), which is a globref;
C$fh will automatically be garbage collected when C$object is destroyed.

{
open my $fh, , /foo/bar;
$table-store($fh, $object, StrongKey = 1);
}
# $fh still exists with a sole reference remaining in the table

Register an attribute type (Cfoo_files), and tag C$fh as being one 
of C$foo_files,

C$fh is still dependent on C$object

# assume $fh is still in scope

$table-register_kt(foo_files);
$table-store_a(1, foo_files, $fh);

Store another Cfoo_file

open my $fh2, , /foo/baz
$table-store_a(1, foo_files, $fh);
# $fh2 will automatically be deleted from the table when it goes 
out of scope

# because we did not specify StrongKey

Get all Cfoo_files

my @foo_files = $table-fetch_a(1, foo_files);

# @foo_files contains ($fh, $fh2);

Get rid of C$object. This can be done in one of the following ways:

# Implicit garbage collection
undef $object;

# Delete by value
$table-purge($object);

# Delete by key ($fh is still stored under the foo_keys attribute)
$table-purgeby($fh);

New module naming

[Trystan]

Hi. I've written few libraries I'd like to release on CPAN and I'm looking
for some advice on how to name them.

I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/,
chapter 5. It's somewhat like a very simple version of Key-Value
Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html#//apple_ref/doc/uid/20001838-SW1.
It's also very similar to
Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut
I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
methods
in order to make the objects searchable within a container.

Here's an example:

 my $a = tbd_name::Object-new();
 my $b = tbd_name::Object-new();

 $a-set( ID, tbd_name::String-new(1234a) );
 $b-set( ID, tbd_name::String-new(1234a) );

 print $a-get(ID);

 $a-equals($b) ? print yes;

 $container = tbd_name::List-new();
 $container-add($a);

 $container-search($b);  #which returns $a

What do I call this thing? I'm thinking the namespace would be 'KeyValue::'
or 'KeyVal::' Would that make sense? (That namespace doesn't seem to be
used.) Should this go in 'Class::'?

Thanks.

Re: New module naming

[sawyer x]

Wow this has turned into a monster thread... ouch.

On Mon, Nov 7, 2011 at 7:42 PM, Shlomi Fish shlo...@shlomifish.org wrote:

 Hi Sawyer,


Hey. :)

The problem is that using my $a and my $b will prevent the built-in $a and
 $b
 from being used and as a result is a bad idea. We should make sure that
 synopses and other code excerpts in the documentation of Perl modules
 reflect
 the Perl best practices, because less clueful people may be tempted to
 duplicate
 them in their own code. And then they go to online forums and ask us why
 their
 code is broken.

 So the lexical $a and $b here should be replaced with something less
 dangerous.


I'm convinced.
I would like to retract my disrespectful poor-taste comment I made earlier.
And no, I'm not being cynical. :)


  We honestly don't have to comment on *everything* people say and do.
  (and I probably shouldn't have commented on what you said either, so
  apologies for that)
 

 Well, I hope I didn't also make the same mistake (again).


Not in my opinion.

Thanks for correcting me. :)
s.

Re: New module naming

[Shlomi Fish]

Hello Sawyer,

On Tue, 8 Nov 2011 17:38:56 +0200
sawyer x xsawy...@gmail.com wrote:

 Wow this has turned into a monster thread... ouch.
 
 On Mon, Nov 7, 2011 at 7:42 PM, Shlomi Fish shlo...@shlomifish.org wrote:
  The problem is that using my $a and my $b will prevent the built-in $a and
  $b
  from being used and as a result is a bad idea. We should make sure that
  synopses and other code excerpts in the documentation of Perl modules
  reflect
  the Perl best practices, because less clueful people may be tempted to
  duplicate
  them in their own code. And then they go to online forums and ask us why
  their
  code is broken.
 
  So the lexical $a and $b here should be replaced with something less
  dangerous.
 
 
 I'm convinced.
 I would like to retract my disrespectful poor-taste comment I made earlier.
 And no, I'm not being cynical. :)
 

Well, I'm glad we agree now, and I should note that your comment wasn't that
bad. You've also raised some points which made me clarify why I think so in
this thread's case.

 
   We honestly don't have to comment on *everything* people say and do.
   (and I probably shouldn't have commented on what you said either, so
   apologies for that)
  
 
  Well, I hope I didn't also make the same mistake (again).
 
 
 Not in my opinion.
 
 Thanks for correcting me. :)
 s.

:-).

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Star Trek: We, the Living Dead - http://shlom.in/st-wtld

JATFM == “Just answer the fabulous man”

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: New module naming

[Shlomi Fish]

Hi Trystan,

On Sun, 6 Nov 2011 16:28:03 -0600
Trystan trysta...@gmail.com wrote:

 Hi. I've written few libraries I'd like to release on CPAN and I'm looking
 for some advice on how to name them.
 
 I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/,
 chapter 5. It's somewhat like a very simple version of Key-Value
 Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1.
 It's also very similar to
 Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut
 I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
 methods
 in order to make the objects searchable within a container.
 
 Here's an example:
 
  my $a = tbd_name::Object-new();
  my $b = tbd_name::Object-new();
 

You shouldn't call lexical variables $a and $b:

http://perl-begin.org/tutorials/bad-elements/#vars-a-and-b

Sorry I cannot help with the actual issue.

Regards,

Shlomi Fish

-- 
-
Shlomi Fish   http://www.shlomifish.org/
Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/

I may be a geek, but I’m a true Klingon geek‐warrior! And a true Klingon geek
warrior ALWAYS bottom‐posts.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: New module naming

[Serguei Trouchelle]

What about Object::KVC, Object::KVC::String, Object::KVC::List?

Trystan wrote:


I found this idea in Head First OOAD http://headfirstlabs.com/books/hfooad/, 
chapter 5. It's somewhat like a very
simple version of Key-Value Coding
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1.
It's also very similar to Object::Generic 
http://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pm
but I didn't use AUTOLOAD and I implemented 'equals' and 'contains' methods in 
order to make the objects searchable
within a container.

Here's an example:

my $a = tbd_name::Object-new(); my $b = tbd_name::Object-new(); $a-set( ID, 
tbd_name::String-new(1234a) );
$b-set( ID, tbd_name::String-new(1234a) ); print $a-get(ID); $a-equals($b) ? 
print yes; $container =
tbd_name::List-new(); $container-add($a); $container-search($b); #which 
returns $a

What do I call this thing? I'm thinking the namespace would be 'KeyValue::' or 
'KeyVal::' Would that make sense? (That
namespace doesn't seem to be used.) Should this go in 'Class::'?

Thanks.



--
Serguei Trouchelle

Re: New module naming

[sawyer x]

On Mon, Nov 7, 2011 at 10:07 AM, Shlomi Fish shlo...@shlomifish.org wrote:


 You shouldn't call lexical variables $a and $b:


That was a completely pointless comment, Shlomi.

He's trying to showcase an action on two objects that have the exact same
level of importance and relevance. Calling them $a and $b is the same as
$homer and $marge or $object1 and $object2 or $first and $second or
anything of that order.

This is a case where $a and $b makes absolute sense. It is also the same
case as Perl's sort() function that uses $a and $b to indicate two values
of the same importance.

We honestly don't have to comment on *everything* people say and do.
(and I probably shouldn't have commented on what you said either, so
apologies for that)

Have a good day,
s.

Re: New module naming

[Trystan]

 What about Object::KVC, Object::KVC::String, Object::KVC::List?

KVC it is.   I had actually been considering that.

In the Object::Generic documentation the author says his module should have
been in the Class:: namespace.

What is the difference between the Object:: namespace and Class:: namespace?

Thanks.

Re: New module naming

[Aristotle Pagaltzis]

* Trystan trysta...@gmail.com [2011-11-06 23:30]:
 I found this idea in Head First
 OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's
 somewhat like a very simple version of Key-Value
 Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1.
 It's also very similar to
 Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut
 I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
 methods in order to make the objects searchable within a container.

 Here's an example:

  my $a = tbd_name::Object-new();
  my $b = tbd_name::Object-new();

  $a-set( ID, tbd_name::String-new(1234a) );
  $b-set( ID, tbd_name::String-new(1234a) );

  print $a-get(ID);

  $a-equals($b) ? print yes;

  $container = tbd_name::List-new();
  $container-add($a);

  $container-search($b);  #which returns $a

 What do I call this thing?

Uhm. So when would I ever use this over a simple hash?

Re: New module naming

[Trystan]

On Mon, Nov 7, 2011 at 12:39 PM, Aristotle Pagaltzis pagalt...@gmx.dewrote:

 * Trystan trysta...@gmail.com [2011-11-06 23:30]:
  I found this idea in Head First
  OOADhttp://headfirstlabs.com/books/hfooad/, chapter 5. It's
  somewhat like a very simple version of Key-Value
  Coding
 http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1
 .
  It's also very similar to
  Object::Generic
 http://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pm
 but
  I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
  methods in order to make the objects searchable within a container.
 
  Here's an example:
 
   my $a = tbd_name::Object-new();
   my $b = tbd_name::Object-new();
 
   $a-set( ID, tbd_name::String-new(1234a) );
   $b-set( ID, tbd_name::String-new(1234a) );
 
   print $a-get(ID);
 
   $a-equals($b) ? print yes;
 
   $container = tbd_name::List-new();
   $container-add($a);
 
   $container-search($b);  #which returns $a
 
  What do I call this thing?

 Uhm. So when would I ever use this over a simple hash?

Re: New module naming

[Bob Parker]

-Original Message-
From: Shlomi Fish shlo...@shlomifish.org
Date: Mon, 7 Nov 2011 19:42:35 +0200
To: sawyer x xsawy...@gmail.com
Cc: Perl Module Authors List module-authors@perl.org
Subject: Re: New module naming

Hi Sawyer,

On Mon, 7 Nov 2011 13:36:58 +0200
sawyer x xsawy...@gmail.com wrote:

 On Mon, Nov 7, 2011 at 10:07 AM, Shlomi Fish shlo...@shlomifish.org
wrote:
 
 
  You shouldn't call lexical variables $a and $b:
 
 

 We honestly don't have to comment on *everything* people say and do.
 (and I probably shouldn't have commented on what you said either, so
 apologies for that)
 

Well, I hope I didn't also make the same mistake (again).

Yeah, you did.

Quite frankly, I have been lurking on this list for years - first through
the web then as an actual subscriber as I currently try to find time in my
schedule to contribute a module that I finally believe to be worthy of
adding to CPAN.

I have seen a multitude of posts from you, Shlomi, and the vast majority
of them have been of the them of I don¹t like the way you are doing it,
because it's not the way *I* would do it, but I really don't have a better
way of doing it myself to contribute.

Nobody likes a know-it-all. Worse yet, nobody likes a know-it-all without
the who doesn't have the credentials to back up their b.s.

In this particular case, pretty much everyone clearly understood that what
was given was a GENERIC EXAMPLE, not real code. It didn't call for code
review, comment or criticism on the use of variables or their naming. What
was requested was feedback on the naming of the MODULE.

There is probably a reason why your suggestions are ignored, for
everything from improving the perl.org site to redesigning the perl
training documentation to ridiculous commentary like this. Dig deep and
you can probably figure it out.

Bob Parker
bob at perldevgeek.com


Regards,

   Shlomi Fish

 Have a good day,
 s.



-- 
-
Shlomi Fish   http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap

You name it ‹ COBOL does not have it.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Politics Personalities - was Re: New module naming

[Bob Parker]

From:  Eirik Berg Hanssen ebhans...@cpan.org
Reply-To:  ebhans...@cpan.org
Date:  Mon, 7 Nov 2011 21:39:15 +0100
To:  Bob Parker b...@perldevgeek.com
Cc:  Shlomi Fish shlo...@shlomifish.org, Perl Module Authors List
module-authors@perl.org
Subject:  Re: New module naming

 On Mon, Nov 7, 2011 at 9:28 PM, Bob Parker b...@perldevgeek.com wrote:
 
 In this particular case, pretty much everyone clearly understood that what
 was given was a GENERIC EXAMPLE, not real code. It didn't call for code
 review, comment or criticism on the use of variables or their naming. What
 was requested was feedback on the naming of the MODULE.
 
   If we're still talking about the generic example:
 
   Publically available code with lexical $a or $b should always come with a
 don't do this (unless you know why you should not do this) warning.
 
   Then again, if we're now talking about what was requested, I'll just note
 that your opinion of Shlomi Fish was not.

Perhaps you are a fan of the guy, perhaps not - I don't know you.

What I do know is that for the past several years, I have seen what should
have been basic and common sense discussions degenerate into personality
wars because of Shlomi Fish. So sue me if I have the balls to call him out
on it. Note that I was not the first, I simply elaborated on someone else's
comment. 

Frankly, I am tired of so many on this list acting like children. Me, me, me
instead of perl, perl, perl. People getting blacklisted because they dare to
speak their minds. Others, with totally valid and valuable contributions
being totally ignored because their ideas are not popular.

I *thought* that we had gone beyond this petty stuff. Clearly I was was
wrong.

 
 
 
 Eirik

Re: New module naming

[Trystan]

 Uhm. So when would I ever use this over a simple hash?

Well I used it because the application I'm working on has a data model with
a lot of variation (I did this instead of creating a massive class
hierarchy). The accessors are the hash key scalar string. The 'equals' and
'contains' methods are delegated to the value objects when keys are eq.
(yes a wrapper object is required for the value but this could be
automated.)This allows fairly complex searches of a container of
objects.

This is based on an idea from a Java tutorial. I think it works better in
Perl than Java because the value objects can be of arbitrary type allowing
the composite hash based object to be more complex if needed.

Taking another swing [was: New module naming]

[Aristotle Pagaltzis]

* sawyer x xsawy...@gmail.com [2011-11-07 12:40]:
 * Shlomi Fish shlo...@shlomifish.org [2011-11-07 18:45]:
  You shouldn't call lexical variables $a and $b:

 That was a completely pointless comment, Shlomi.

Only in sending it to the list instead of as a private comment, and in
his way of stating it – as a do-not instead of a suggestion, followed by
the reason, followed by an off-topic disclaimer. In the opposite order
it would have gone down easy. (OK: and if it didn’t come from Shlomi.
Even if he gets better at tone now his reputation would haunt him.)

 This is a case where $a and $b makes absolute sense. It is also the
 same case as Perl's sort() function that uses $a and $b to indicate
 two values of the same importance.

There is no real case in which `my $a` or `my $b` make sense in Perl,
only a handful of cases where they don’t make no sense. I think his
point was a reasonable one, if minor.


* Bob Parker b...@perldevgeek.com [2011-11-07 21:30]:
 * Shlomi Fish shlo...@shlomifish.org [2011-11-07 09:25]:
  Well, I hope I didn't also make the same mistake (again).

 Yeah, you did.

 Quite frankly, I have been lurking on this list for years - first
 through the web then as an actual subscriber as I currently try to
 find time in my schedule to contribute a module that I finally believe
 to be worthy of adding to CPAN.

 I have seen a multitude of posts from you, Shlomi, and the vast
 majority of them have been of the them of I don¹t like the way you
 are doing it, because it's not the way *I* would do it, but I really
 don't have a better way of doing it myself to contribute.

 Nobody likes a know-it-all.

But the perpetrators of drive-by ad hominems are popular? Particularly
ones who come out of the woodworks to beat on the community punchbag
after he has already apologized?

 Worse yet, nobody likes a know-it-all without the who doesn't have the
 credentials to back up their b.s.

You made a mistake to bring up credentials.

His have-to-fix-that attitude has driven Shlomi to pick up the upkeep
chores of a whole raft of neglected high-profile CPAN modules, and there
are quite a few perl patches to his name. Not all of them have been
applied, bless his eager heart :-), but neither have all of them gone
unappreciated.

That looks like a lot more in credentials than you brought to the table.

Sure, Shlomi suffers from overly rigid ideas of how to do things and is
too eager to dismiss the “old” way along with all other options. But he
isn’t stupid either, and he doesn’t just nitpick but contributes.

Nor is he is in the habit of flaming people, much less talking about them
without knowing who he is talking about.

That’s a lot more than can be said about some people.

 In this particular case, pretty much everyone clearly understood that
 what was given was a GENERIC EXAMPLE, not real code. It didn't call
 for code review, comment or criticism on the use of variables or their
 naming. What was requested was feedback on the naming of the MODULE.

His point was valid, clumsy though his way of stating it was. The abuse
he invited with his clumsiness is out of all proportion for his sin.

 There is probably a reason why your suggestions are ignored, for
 everything from improving the perl.org site to redesigning the perl
 training documentation to ridiculous commentary like this. Dig deep
 and you can probably figure it out.

A lot of them are ignored. A lot of them are not.

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

Re: Politics Personalities - was Re: New module naming

[Aristotle Pagaltzis]

* Bob Parker b...@perldevgeek.com [2011-11-07 22:15]:
 Perhaps you are a fan of the guy, perhaps not - I don't know you.

Perhaps it doesn’t even matter.

Perhaps you can be a decent person to someone you dislike.

 What I do know is that for the past several years, I have seen what
 should have been basic and common sense discussions degenerate into
 personality wars because of Shlomi Fish. So sue me if I have the balls
 to call him out on it. Note that I was not the first, I simply
 elaborated on someone else's comment.

No. You had the no-balls to come out behind someone else and follow up
on an apology by beating on him some more.

Congratulations, I hope you’re proud.

 Frankly, I am tired of so many on this list acting like children. Me,
 me, me instead of perl, perl, perl. People getting blacklisted because
 they dare to speak their minds. Others, with totally valid and
 valuable contributions being totally ignored because their ideas are
 not popular.

 I *thought* that we had gone beyond this petty stuff. Clearly I was was
 wrong.

Pot, kettle.

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

Re: Taking another swing [was: New module naming]

[Bob Parker]

Clearly you are another fanboy of Shlomi's.

-Original Message-
From: Aristotle Pagaltzis pagalt...@gmx.de
Date: Mon, 7 Nov 2011 23:46:02 +0100
To: Perl Module Authors List module-authors@perl.org
Subject: Taking another swing [was: New module naming]

* sawyer x xsawy...@gmail.com [2011-11-07 12:40]:
 * Shlomi Fish shlo...@shlomifish.org [2011-11-07 18:45]:
  You shouldn't call lexical variables $a and $b:

 That was a completely pointless comment, Shlomi.

Only in sending it to the list instead of as a private comment, and in
his way of stating it ­ as a do-not instead of a suggestion, followed by
the reason, followed by an off-topic disclaimer. In the opposite order
it would have gone down easy. (OK: and if it didn’t come from Shlomi.
Even if he gets better at tone now his reputation would haunt him.)

 This is a case where $a and $b makes absolute sense. It is also the
 same case as Perl's sort() function that uses $a and $b to indicate
 two values of the same importance.

There is no real case in which `my $a` or `my $b` make sense in Perl,
only a handful of cases where they don’t make no sense. I think his
point was a reasonable one, if minor.

Once again, you too have missed the point. The original post was AN
EXAMPLE. At now point was it intended to be usable code in which any
reasonable person would be expected to literally use $a or $b. Shlomi was
nitpicking for the purpose of nitpicking, so as to get his 2￠ in there,
not for the purpose of contributing to the conversation as it his known to
do on a regular basis. In other words, he was stirring up trouble for no
reason. 

If this was anyone else BUT Shlomi, we wouldn't even be having this
discussion. For whatever reason, you feel the need to defend him against
the newcomer who dares to speak up against the status quo.



* Bob Parker b...@perldevgeek.com [2011-11-07 21:30]:
 * Shlomi Fish shlo...@shlomifish.org [2011-11-07 09:25]:
  Well, I hope I didn't also make the same mistake (again).

 Yeah, you did.

 Quite frankly, I have been lurking on this list for years - first
 through the web then as an actual subscriber as I currently try to
 find time in my schedule to contribute a module that I finally believe
 to be worthy of adding to CPAN.

 I have seen a multitude of posts from you, Shlomi, and the vast
 majority of them have been of the them of I don¹t like the way you
 are doing it, because it's not the way *I* would do it, but I really
 don't have a better way of doing it myself to contribute.

 Nobody likes a know-it-all.

But the perpetrators of drive-by ad hominems are popular? Particularly
ones who come out of the woodworks to beat on the community punchbag
after he has already apologized?

There was an apology?


 Worse yet, nobody likes a know-it-all without the who doesn't have the
 credentials to back up their b.s.

You made a mistake to bring up credentials.

His have-to-fix-that attitude has driven Shlomi to pick up the upkeep
chores of a whole raft of neglected high-profile CPAN modules, and there
are quite a few perl patches to his name. Not all of them have been
applied, bless his eager heart :-), but neither have all of them gone
unappreciated.

That looks like a lot more in credentials than you brought to the table.

Honestly, you don't know me or my credentials. You have seen exactly 2
posts of mine on this mailing list - the grand total my contributions to
the list to date. The reason I haven't contributed so far is because of
back-biting, political, personal attacks like you have demonstrated so
well here. To hell with furthering the cause of the language - let's form
cliques and screw with those people who disagree with us, regardless of
what they think.

I have followed the career of Shlomi over the years since he first
appeared on the scene. His very first appearances were full of strife and
controversy. Sure, he may have taken over some projects, but not without
disagreement and/or opposition.


Sure, Shlomi suffers from overly rigid ideas of how to do things and is
too eager to dismiss the “old” way along with all other options. But he
isn’t stupid either, and he doesn’t just nitpick but contributes.

No, not exactly. Based on this early postings that were full of criticisms
and nitpicks of the various perl.org sites, Shlomi had PLENTY to say about
those sites that certainly qualified as nitpicking. Yes, he has
contributed to CPAN. Goodie for him. CPAN contributes are not the be
all/end all of a person's worth, however.


Nor is he is in the habit of flaming people, much less talking about them
without knowing who he is talking about.

Based on his previous postings to this and other lists, that's not exactly
true.


That’s a lot more than can be said about some people.

That's quite a leap to make from 1 or 2 posts to the list to a generalized
statement. If you don't like me based on your personal experience with me
so far, then just say so. I'm a big boy, I can take it. Based on your
responses to me, I

Re: Taking another swing [was: New module naming]

[Aristotle Pagaltzis]

* Bob Parker b...@perldevgeek.com [2011-11-08 00:30]:
 Clearly you are another fanboy of Shlomi's.

You found me out. I am two days short of proposing gay marriage to him.

 * Aristotle Pagaltzis pagalt...@gmx.de [2011-11-07 23:50]:
 * sawyer x xsawy...@gmail.com [2011-11-07 12:40]:
 This is a case where $a and $b makes absolute sense. It is also the
 same case as Perl's sort() function that uses $a and $b to indicate
 two values of the same importance.
 
 There is no real case in which `my $a` or `my $b` make sense in Perl,
 only a handful of cases where they don’t make no sense. I think his
 point was a reasonable one, if minor.

 Once again, you too have missed the point. The original post was AN
 EXAMPLE. At now point was it intended to be usable code in which any
 reasonable person would be expected to literally use $a or $b.

Thanks for pointing it out. I would not have realised this without your
helpful contribution.

In the real world people learn by copy-pasting code and tweaking until
it seems to do what they wanted. Every code example should be as close
to real working code as possible, ideally *should* be real working code;
or else so broken (by missing declarations and what have you) that it
cannot be made to work accidentally.

 Shlomi was nitpicking for the purpose of nitpicking

Hip hip hooray for projection.

 so as to get his 2￠in there, not for the purpose of contributing to
 the conversation as it his known to do on a regular basis. In other
 words, he was stirring up trouble for no reason.

No, I believe that was you. You provided no value WHATSOEVER – your
comment contained zero technical content, which Shlomi’s at least did,
even if it was off-topic.

But you had to get your utterly worthless 2￠ in there.

 If this was anyone else BUT Shlomi, we wouldn't even be having this
 discussion. For whatever reason, you feel the need to defend him
 against the newcomer who dares to speak up against the status quo.

I am not defending anyone. Shlomi was too brash, but then Sawyer was
too, and then finally comes here someone whose grand debut consists in
lashing out. Some entry. Welcome to you too sir.

 But the perpetrators of drive-by ad hominems are popular?
 Particularly ones who come out of the woodworks to beat on the
 community punchbag after he has already apologized?

 There was an apology?

Start by reading harder next time.

 Worse yet, nobody likes a know-it-all without the who doesn't have
 the credentials to back up their b.s.
 
 You made a mistake to bring up credentials.
 
 His have-to-fix-that attitude has driven Shlomi to pick up the upkeep
 chores of a whole raft of neglected high-profile CPAN modules, and
 there are quite a few perl patches to his name. Not all of them have
 been applied, bless his eager heart :-), but neither have all of them
 gone unappreciated.
 
 That looks like a lot more in credentials than you brought to the
 table.

 Honestly, you don't know me or my credentials.

No. You just made a point of pointing them out.

 You have seen exactly 2 posts of mine on this mailing list - the grand
 total my contributions to the list to date.

You should be proud of yourself! Your track record so far is stellar.

 The reason I haven't contributed so far is because of back-biting,
 political, personal attacks like you have demonstrated so well here.
 To hell with furthering the cause of the language - let's form cliques
 and screw with those people who disagree with us, regardless of what
 they think.

More projection.

Why does the back-biting bother you so much when your grand act of entry
to this list is to turn the dial to 11 on back-biting?

 I have followed the career of Shlomi over the years since he first
 appeared on the scene. His very first appearances were full of strife
 and controversy. Sure, he may have taken over some projects, but not
 without disagreement and/or opposition.

I never eulogised him.

I am just not going to let you get away with justifying your ad hominem
by demonising him.

 Sure, Shlomi suffers from overly rigid ideas of how to do things and
 is too eager to dismiss the “old” way along with all other options.
 But he isn’t stupid either, and he doesn’t just nitpick but
 contributes.

 No, not exactly. Based on this early postings that were full of
 criticisms and nitpicks of the various perl.org sites, Shlomi had
 PLENTY to say about those sites that certainly qualified as
 nitpicking. Yes, he has contributed to CPAN. Goodie for him. CPAN
 contributes are not the be all/end all of a person's worth, however.

Thanks for dismantling my point and missing all essence.

My point was that he puts his money where his mouth is.

He wants things a certain way; he works to make that happen. If you
don’t like the way he wants things to be, push back. If he’s badgering
someone who should be encouraged, take the badgered’s side. Lashing out
at him achieves nothing but to turn the lists into the unpleasant places
you made them out to be.

 Nor is 

Re: Taking another swing [was: New module naming]

[Bob Parker]

Aristotle you are, by your words and deeds in this thread, what was
known in my days in school as a bully. Apparently age and so-called
maturity has not changed that.

At this point I choose to ignore you publicly and forego further response,
because we have already taken up too much of the mailing list's time.

If you have anything further to say, you can say it privately.

-Original Message-
From: Aristotle Pagaltzis pagalt...@gmx.de
Date: Tue, 8 Nov 2011 02:22:15 +0100
To: Perl Module Authors List module-authors@perl.org
Subject: Re: Taking another swing [was: New module naming]

* Bob Parker b...@perldevgeek.com [2011-11-08 00:30]:
 Clearly you are another fanboy of Shlomi's.

You found me out. I am two days short of proposing gay marriage to him.

 * Aristotle Pagaltzis pagalt...@gmx.de [2011-11-07 23:50]:
 * sawyer x xsawy...@gmail.com [2011-11-07 12:40]:
 This is a case where $a and $b makes absolute sense. It is also the
 same case as Perl's sort() function that uses $a and $b to indicate
 two values of the same importance.
 
 There is no real case in which `my $a` or `my $b` make sense in Perl,
 only a handful of cases where they don’t make no sense. I think his
 point was a reasonable one, if minor.

 Once again, you too have missed the point. The original post was AN
 EXAMPLE. At now point was it intended to be usable code in which any
 reasonable person would be expected to literally use $a or $b.

Thanks for pointing it out. I would not have realised this without your
helpful contribution.

In the real world people learn by copy-pasting code and tweaking until
it seems to do what they wanted. Every code example should be as close
to real working code as possible, ideally *should* be real working code;
or else so broken (by missing declarations and what have you) that it
cannot be made to work accidentally.

 Shlomi was nitpicking for the purpose of nitpicking

Hip hip hooray for projection.

 so as to get his 2￠in there, not for the purpose of contributing to
 the conversation as it his known to do on a regular basis. In other
 words, he was stirring up trouble for no reason.

No, I believe that was you. You provided no value WHATSOEVER ­ your
comment contained zero technical content, which Shlomi’s at least did,
even if it was off-topic.

But you had to get your utterly worthless 2￠ in there.

 If this was anyone else BUT Shlomi, we wouldn't even be having this
 discussion. For whatever reason, you feel the need to defend him
 against the newcomer who dares to speak up against the status quo.

I am not defending anyone. Shlomi was too brash, but then Sawyer was
too, and then finally comes here someone whose grand debut consists in
lashing out. Some entry. Welcome to you too sir.

 But the perpetrators of drive-by ad hominems are popular?
 Particularly ones who come out of the woodworks to beat on the
 community punchbag after he has already apologized?

 There was an apology?

Start by reading harder next time.

 Worse yet, nobody likes a know-it-all without the who doesn't have
 the credentials to back up their b.s.
 
 You made a mistake to bring up credentials.
 
 His have-to-fix-that attitude has driven Shlomi to pick up the upkeep
 chores of a whole raft of neglected high-profile CPAN modules, and
 there are quite a few perl patches to his name. Not all of them have
 been applied, bless his eager heart :-), but neither have all of them
 gone unappreciated.
 
 That looks like a lot more in credentials than you brought to the
 table.

 Honestly, you don't know me or my credentials.

No. You just made a point of pointing them out.

 You have seen exactly 2 posts of mine on this mailing list - the grand
 total my contributions to the list to date.

You should be proud of yourself! Your track record so far is stellar.

 The reason I haven't contributed so far is because of back-biting,
 political, personal attacks like you have demonstrated so well here.
 To hell with furthering the cause of the language - let's form cliques
 and screw with those people who disagree with us, regardless of what
 they think.

More projection.

Why does the back-biting bother you so much when your grand act of entry
to this list is to turn the dial to 11 on back-biting?

 I have followed the career of Shlomi over the years since he first
 appeared on the scene. His very first appearances were full of strife
 and controversy. Sure, he may have taken over some projects, but not
 without disagreement and/or opposition.

I never eulogised him.

I am just not going to let you get away with justifying your ad hominem
by demonising him.

 Sure, Shlomi suffers from overly rigid ideas of how to do things and
 is too eager to dismiss the “old” way along with all other options.
 But he isn’t stupid either, and he doesn’t just nitpick but
 contributes.

 No, not exactly. Based on this early postings that were full of
 criticisms and nitpicks of the various perl.org sites, Shlomi had
 PLENTY to say about those sites

Re: Taking another swing [was: New module naming]

[Aristotle Pagaltzis]

* Bob Parker b...@perldevgeek.com [2011-11-08 04:55]:
 Aristotle you are, by your words and deeds in this thread, what was
 known in my days in school as a bully. Apparently age and so-called
 maturity has not changed that.

Hating Shlomi does not justify bullying him and painting me as the bully
for not letting you get away with it does not absolve you.

 At this point I choose to ignore you publicly and forego further
 response, because we have already taken up too much of the mailing
 list's time.

Yes please.

 If you have anything further to say, you can say it privately.

No thanks.

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

Re: New module naming

[Eirik Berg Hanssen]

On Mon, Nov 7, 2011 at 9:28 PM, Bob Parker b...@perldevgeek.com wrote:


 In this particular case, pretty much everyone clearly understood that what
 was given was a GENERIC EXAMPLE, not real code. It didn't call for code
 review, comment or criticism on the use of variables or their naming. What
 was requested was feedback on the naming of the MODULE.


  If we're still talking about the generic example:

  Publically available code with lexical $a or $b should always come with a
don't do this (unless you know why you should not do this) warning.

  Then again, if we're now talking about what was requested, I'll just
note that your opinion of Shlomi Fish was not.


Eirik

Re: New module naming

[Eirik Berg Hanssen]

On Mon, Nov 7, 2011 at 12:36 PM, sawyer x xsawy...@gmail.com wrote:

 This is a case where $a and $b makes absolute sense. It is also the same
 case as Perl's sort() function that uses $a and $b to indicate two values
 of the same importance.


  ... except declaring them as lexicals still _breaks_ their use in sort {
} in the same scope.

  ... and _silently_ breaks a naïve mysort { } in the same scope.  Even
with strict and warnings!

  This is a case where pointing out the shortcomings of lexical $a and $b
makes absolute sense.  Frankly, every sample code with lexical $a or $b is
such a case.


Eirik

Re: Taking another swing [was: New module naming]

[Zbigniew Łukasiak]

On Tue, Nov 8, 2011 at 2:22 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:

...

 In the real world people learn by copy-pasting code and tweaking until
 it seems to do what they wanted. Every code example should be as close
 to real working code as possible, ideally *should* be real working code;
 or else so broken (by missing declarations and what have you) that it
 cannot be made to work accidentally.

...


 No, I believe that was you. You provided no value WHATSOEVER – your
 comment contained zero technical content, which Shlomi’s at least did,
 even if it was off-topic.

Well - actually I believe that this is something that needs some
discussion - so I think it is positive that it was explained.  The
psychoanalitic rest was rather redundant - I agree.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

New module naming

[Trystan]

Hi. I've written few libraries I'd like to release on CPAN and I'm looking
for some advice on how to name them.

I found this idea in Head First OOADhttp://headfirstlabs.com/books/hfooad/,
chapter 5. It's somewhat like a very simple version of Key-Value
Codinghttp://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/Overview.html%23//apple_ref/doc/uid/20001838-SW1.
It's also very similar to
Object::Generichttp://search.cpan.org/%7Ejmahoney/Object-Generic-0.13/lib/Object/Generic.pmbut
I didn't use AUTOLOAD and I implemented 'equals' and 'contains'
methods
in order to make the objects searchable within a container.

Here's an example:

 my $a = tbd_name::Object-new();
 my $b = tbd_name::Object-new();

 $a-set( ID, tbd_name::String-new(1234a) );
 $b-set( ID, tbd_name::String-new(1234a) );

 print $a-get(ID);

 $a-equals($b) ? print yes;

 $container = tbd_name::List-new();
 $container-add($a);

 $container-search($b);  #which returns $a

What do I call this thing? I'm thinking the namespace would be 'KeyValue::'
or 'KeyVal::' Would that make sense? (That namespace doesn't seem to be
used.) Should this go in 'Class::'?

Thanks.

Module Naming Suggestion - Carp from somewhere else

[Paul LeoNerd Evans]

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


signature.asc
Description: Digital signature

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.

Fwd: Module naming - Test::Import::DontRun

[Charles Colbourn]

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

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

Module naming - Test::Import::DontRun

[Charles Colbourn]

Hi,

I have a module that attempts to import scripts/modules without
executing anything in top level scope, so that test scripts can import
their functions/methods and test them. Is Test::Import::DontRun a
sufficiently descriptive name? I also thought about Test::DontRun, and
Test::DontExecute, but prefer Test::Import::DontRun as more
descriptive.

thanks,

Charles.

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

Module Naming

[perl-module-author . alias]

 Hi there.

Was reading the information available at the PAUSE website and it 
suggested getting your opinions for the naming of the module I want to 
upload


It's working title is Device::Aurora.

It provides the protocol and constants required for communicating with a 
Power-One Aurora Inverter over a serial port (In fact it uses 
Device::SerialPort or Win32::SerialPort on windows).


Is the current name sufficient?
Any suggestions for improvements?

Kind regards

Shannon.

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: Yet another module naming suggestion query

[Tim Bunce]

On Tue, Apr 06, 2010 at 01:07:33AM +0300, Sawyer X wrote:
On Mon, Apr 5, 2010 at 11:29 PM, Tim Bunce [1]tim.bu...@pobox.com wrote:
 
  Data is fairly meaningless as a name. The Data:: is intended to be
  used for modules that work with abstract data values: Data::Bind,
  Data::Bucket, Data::BitMask, Data::COW etc.
 
Thank you for taking the time to comment!
 
Meanwhile, while writing all the docs in order to be able to release 
 properly to CPAN, I've also renamed
it to Data::Collector. I think it's a more accurate term than 
 Data::Scanner, since it doesn't really
scan anything. It provides a small framework for collecting information.
 
  There's a Sys:: namespace that has things like Sys::Info. (Perhaps you
  could integrate with that.)
 
Even though I will be using this in a system environment (trying to get 
 information on the system -
where Sys::Info might be useful), Data::Collector was built with 
 flexibility in mind, and can be used
for things not related to a system at all.
 
You could write Data::Collector::Info::Dilbert to have a piece of info 
 that fetches Dilbert comics, for
example. You could have a Data::Collector::Info::MyCorpIncCustomerInfo and 
 so on. Pretty much like
plugins so anything homegrown can be used with it without altering 
 anything. I reckon that's why
settling down to a specific type of data will not be right.
 
  Generally speaking the more specialized the module the more
  words-per-level the name should have.
 
I reckon that is why Sys::Collector is probably not a good bet, since it's 
 not necessarily system
information.
It gets even trickier since the data can be returned in various forms 
 (XML, JSON, Data::Dumper. YAML,
Perl objects - these I had already implemented as Data::Collector core 
 serializing engines along the
way).
 
Thanks again, I appreciate the response, it helped me understand it more.
 
Abstract data values seems like what I'm going for, so it looks like a 
 good match.

You could write Data::Collector::Info::Dilbert to have a piece of info
that fetches Dilbert comics. That's far from abstract in the sense that
Data:: was indended for.

I believe you're thinking of what I'd call generic, and you called it
a framework yourself.

On CPAN frameworks, especially generic ones with plugins etc., are
encouraged to have brand names. Think Catalyst, Mojo, Smolder, Plack,
Dist::Zilla to name a few off the top of my head.

Posting the docs may help.

Tim.

Re: Yet another module naming suggestion query

[nadim khemir]

 To take perhaps a short break from mirror efficiency discussions, are people
 still up for module naming suggestions? :)
 
 I have a new module (which I'll probably release to CPAN soon enough) which
 basically scans a machine for information (like Puppet's Facter).
 
 The working title is Data::Scanner, but perhaps that doesn't really cover
 it.
 Perhaps Data::Collector would be better, since it collects information.
 I'd love for a name that also sounds like an application since it has a CLI
 frontend as well.
 
 I'd appreciate suggestions to make this more searchable and coherent.
 
 S.

Hi, 

It's difficult to help you with any name as I lack information about what the 
module is really doing. As for Data::Scanner or Data::Collector, those would 
be very bad names as they are so generic they mean nothing.

Most modern apps have moved to the APP::* root namespace although I believe 
that sub modules, part of the application, that are of general use should 
still be rooted in the relevant namespace.


Please give us more information or better yet put the documentation on-line. 

Cheers, Nadim.

Re: Yet another module naming suggestion query

[Sawyer X]

On Mon, Apr 5, 2010 at 11:29 PM, Tim Bunce tim.bu...@pobox.com wrote:

  Data is fairly meaningless as a name. The Data:: is intended to be
 used for modules that work with abstract data values: Data::Bind,
 Data::Bucket, Data::BitMask, Data::COW etc.


Thank you for taking the time to comment!

Meanwhile, while writing all the docs in order to be able to release
properly to CPAN, I've also renamed it to Data::Collector. I think it's a
more accurate term than Data::Scanner, since it doesn't really scan
anything. It provides a small framework for collecting information.


 There's a Sys:: namespace that has things like Sys::Info.  (Perhaps you
 could integrate with that.)


Even though I will be using this in a system environment (trying to get
information on the system - where Sys::Info might be useful),
Data::Collector was built with flexibility in mind, and can be used for
things not related to a system at all.

You could write Data::Collector::Info::Dilbert to have a piece of info that
fetches Dilbert comics, for example. You could have a
Data::Collector::Info::MyCorpIncCustomerInfo and so on. Pretty much like
plugins so anything homegrown can be used with it without altering anything.
I reckon that's why settling down to a specific type of data will not be
right.


 Generally speaking the more specialized the module the more
 words-per-level the name should have.


I reckon that is why Sys::Collector is probably not a good bet, since it's
not necessarily system information.
It gets even trickier since the data can be returned in various forms (XML,
JSON, Data::Dumper. YAML, Perl objects - these I had already implemented as
Data::Collector core serializing engines along the way).

Thanks again, I appreciate the response, it helped me understand it more.

Abstract data values seems like what I'm going for, so it looks like a
good match.

S.

Yet another module naming suggestion query

[Sawyer X]

To take perhaps a short break from mirror efficiency discussions, are people
still up for module naming suggestions? :)

I have a new module (which I'll probably release to CPAN soon enough) which
basically scans a machine for information (like Puppet's Facter).

The working title is Data::Scanner, but perhaps that doesn't really cover
it.
Perhaps Data::Collector would be better, since it collects information.
I'd love for a name that also sounds like an application since it has a CLI
frontend as well.

I'd appreciate suggestions to make this more searchable and coherent.

S.

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.

comments for module naming

[Jerome Quelin]

hello,

i'm looking for a vector module to be used in Language::Befunge.
currently, i provide Language::Befunge::Vector which is a pure perl
version of what i'm looking for.

my requirements:
 - n dimensions, ie, not limited to 2D (x,y) or 3D (x,y,z)
 - integer values
 - basic operations on them (addition, substraction, etc)
 - fast, ie not pure perl

this seems to remove all the existing cpan modules but PDL. but PDL
seems a bit big for what i need... or isn't it?


therefore, i was planning to:
 1- remove Language::Befunge::Vector from Language::Befunge and release
it as a new module
 2- provide a new XS module with the same interface, overwriting module
1- (same as Readonly::XS does with Readonly)
 3- require module 1-  recommend module 2- in Language::Befunge

this has the added benefit over PDL that i can fallback on pure-perl
module for machines that don't have a compiler.

so now here's my question: how should i name my modules?
(maybe the first question would be: do you think i'm doing sthg wise or
would you recommend to use PDL?)

i thought of:
 - Math::Vector
 - Math::Vector::Integer (i deal with integer only)
 - Math::Vector::NDims   (i deal with more than 3 dims)
 - Math::NDimVector
 - other?


wdyt?
jérôme 
-- 
[EMAIL PROTECTED]