Re: Namespace advice for Git-related package

[Smylers]

James E Keenan writes:

> I am in the process of developing a CPAN library which I am
> considering calling Git-Multisect-Perl. ...
> 
> 'Multisect::' is chosen to contrast with 'bisect'.

That hadn't occurred to me. I read it as a contraction of ‘multiple
sections’ or similar.

> When we speak of bisection in the context of, say, Perl 5 core
> development and use of Porting/bisect.pl, we're usually looking for a
> single answer to a question, e.g., at which specific commit did this
> test file start to experience failures.  Recently, however, we have a
> case where a file failed in different ways over many months.  That's
> the actual use case which led me to develop this library.

However, ‘bisect’ is a well known word for this activity. Sometimes with
naming things it's clearer to be familiar-but-approximate rather than
accurate-but-obscure. Once the name has got somebody's attention, the
docs can explain nuances.

I think Git::MultiBisect or Git::Bisect::Multiple get the idea across
more obviously.

> The '::Perl' in the namespace is intended to say, "This is a way to
> apply the concept of multisection to typical needs in Perl development

Unfortunately I don't think it does that.

A suffix of ::Perl usually indicates that it's implemented in Perl —
either because there's also an ::XS variant, or it's a port of a library
that originated in Java or some other language.

I'm not sure there is anything which indicates ‘typical for Perl
development’. I'd omit that aspect from the name.

> we don't want to foreclose the possibility of future libraries which
> use git to perform multisection in other problem spaces."

Let any hypothetical future rival Git-multi-bisect distribution — and
there may not be one — come up with an adjective that distinguishes
itself from yours.

Alternatively, Devel::Git::MultiBisect would indicate that this is a
tool for Perl development use.

Good luck!

Smylers
-- 
http://twitter.com/Smylers2

Re: PDLx::Mask - search.cpan.org uses README.pod instead of lib/PDLx/Mask.pm

[Diab Jerius]

Thanks.  I'll move the README.pod somewhere innocuous.


On Wed, Oct 26, 2016 at 6:52 PM, Dan Book  wrote:
> On Wed, Oct 26, 2016 at 6:14 PM, Diab Jerius 
> wrote:
>>
>> Howdy,
>>
>> The PDLx-Mask distribution has a README.pod file at the top level, as
>> well as actual module documentation in lib/PDLx/Mask.pm.
>>
>> On the module's main page:
>>
>>   http://search.cpan.org/~djerius/PDLx-Mask-0.01/
>>
>> The PDLx::Mask link goes to README.pod, not to lib/PDLx/Mask.pm
>>
>> That's not quite what I expected, while this
>>
>>   https://metacpan.org/pod/PDLx::Mask
>>
>> is.
>>
>> Should I not be uploading the README.pod file? I use that to
>> generate README and README.md.
>>
>> Thanks,
>>
>> Diab
>
>
> You should not upload any .pod files in the top level of the distribution,
> as they will get indexed and installed for historical reasons. (Metacpan
> sees the name in that document as PDLx::Mask, so it does not override the
> indexed PDLx::Mask documentation in their index. Search.cpan.org clearly has
> different logic we are not privy to.) README.md and README are fine.
>
> -Dan

Re: How to avoid circular module dependencies within a distribution?

[Alex Muntada]

David Christensen:

> Here is a contrived example that shows circular modular dependency
> without circular subroutine dependency:

In this particular case, I'd move subs bar2 and foo2 to another
module FooBar.pm, and have Foo.pm and Bar.pm import those subs
from FooBar.pm instead:

> 2016-10-19 11:05:08 dpchrist@t7400 ~/sandbox/perl/circular-dependency
> $ cat Foo.pm
> package Foo;
> use strict;
> use warnings;
> require Exporter;
> our @ISA = qw( Exporter );
> our @EXPORT = qw( foo1 foo2 );
> use Bar;
> sub foo1 { print "foo1\n"; bar2(); }
> sub foo2 { print "foo2\n"; }

package Foo;
use strict;
use warnings;
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( foo1 );
use FooBar;
sub foo1 { print "foo1\n"; bar2(); }

> 2016-10-19 11:05:10 dpchrist@t7400 ~/sandbox/perl/circular-dependency
> $ cat Bar.pm
> package Bar;
> use strict;
> use warnings;
> require Exporter;
> our @ISA = qw( Exporter );
> our @EXPORT = qw( bar1 bar2 );
> use Foo;
> sub bar1 { print "bar1\n"; foo2(); }
> sub bar2 { print "bar2\n"; }

package Bar;
use strict;
use warnings;
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( bar1 );
use FooBar;
sub bar1 { print "bar1\n"; foo2(); }

# FooBar.pm
package FooBar;
use strict;
use warnings;
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( foo2 bar2 );
sub foo2 { print "foo2\n"; }
sub bar2 { print "bar2\n"; }

Deciding if bar2 and foo2 will go together or separatedly depends
mostly on the problem at hand, so I'm suggesting the shortest
path (i.e. together) with the information I have.

Cheers,
Alex

Re: Sanity checking for namespace and other abuses

[Aristotle Pagaltzis]

* David Mertens  [2016-10-26 18:12]:
> Does anybody oppose me adding to code to top-level, lower-cased
> packages "int", "num", and "str"? What about top-level packages "Int",
> "UInt", "Str", or "Num"? Do other type systems use these top-level
> packages?

Yes. You would either be reserving them for yourself across all of CPAN,
unless you no_index them, in which case you would merely be making it
probably-impossible to use your module together with another one that
might also want to use these packages. (Which doesn’t have to be a CPAN
module, it can also be some would-be user’s already-existing code base.)

It will be uglier to namespace your stuff more; bite that bullet.

Regards,
-- 
Aristotle Pagaltzis //