in reply to Is there an official regex for checking module names?

Technically, you can create packages and variables with pretty much any name. But let's assume you are referring to the ones you could use without taking special measures. Your pattern has at least four problems:

$ perl -we'package ::' && echo ok ok
$ perl -we'package _a;' && echo ok ok
$ perl -Mutf8 -we'package é;' && echo ok ok
$ perl -we'package aaaa::::::bbbb;' && echo ok ok

The first one is occasionally used. It refers to the root package (for which main is an alias), so %:: is Perl's symbol table, $_ means $::_, etc.

I haven't seen any instances of the second and third, but there's nothing overly special about them.

I wouldn't consider the final one valid (even though it was accepted).

Replies are listed 'Best First'.
Re^2: Is there an official regex for checking module names?
by kcott (Archbishop) on Feb 08, 2022 at 22:15 UTC

    G'day ikegami,

    Thanks for the feedback. As mentioned, this is for a $work project, which has various contraints, so some of these "exotic" forms wouldn't come up anyway. Quickly working through the list:

    1. I'm familiar with "::" but it wouldn't pass code review (cleverness reducing readability). It would need to be changed to "package main".
    2. While "_a" probably wouldn't pass code review (non-meaningful name) it does match the pattern: I added it the original code and got "ok 8 - Testing _a". I do use names with a leading undersore in t/name.t scripts: typically prepending Some::Work::Module with _Test::, _Mock::, or similar.
    3. As already stated, non-ASCII names are disallowed ($work constraint).
    4. Like you, I wouldn't have considered "aaaa::::::bbbb" to be valid. It wouldn't pass code review. Possibly flagged with "too damn weird; are you drunk?". :-)

    — Ken

      I'm familiar with "::" but it wouldn't pass code review (cleverness reducing readability)

      No, it's not being clever.

      Do you write package main::Foo::Bar; or package Foo::Bar;? So why do you expect me to use %main:: instead of %::? If I want the root namespace, that's what I use. Not some alias created so you can say "scripts run in main".

      Also, using Foo::->method instead of Foo->method solves a real problem. Again, not cleverness.

      While "_a" probably wouldn't pass code review (non-meaningful name) it does match the pattern

      oops! I saw the pattern for the lead character was shorter, and I somehow imagined that "_" wasn't included.

      As already stated, non-ASCII names are disallowed ($work constraint).

      That was not mentioned in the question. And you're not the only person using PerlMonks.

        I believe you have taken my comment about "::" completely out of context. You wrote "package ::" which is very obscure — I actually don't think I've seen it previously — for $work, I'd expect "package main", which is common and generally understood.

        "So why do you expect me to use %main:: instead of %::?"

        I've no idea where that comes from. I did not voice such an expectation of you or anyone else.

        "Also, using Foo::->method ..."

        Again, I've no idea where that comes from; it wasn't mentioned in my post. In fact, I encourage the use of "::->" over just "->".

        "That was not mentioned in the question."

        My reply to you had "As mentioned, ...".

        "And you're not the only person using PerlMonks."

        Why write that?

        — Ken

Re^2: Is there an official regex for checking module names? (updated)
by LanX (Saint) on Feb 08, 2022 at 23:14 UTC
    > I wouldn't consider the final one valid (even though it was accepted).

    It was accepted as package name, but as a module it would hit a wall, ° since :: are translated to path delimiter /

    DB<83> use a::::b Can't locate a//b.pm in @INC

    I'm not sure if there are any file-systems with semantics for an unnamed directory between two '/', win at least gives me a hard time trying to create a directory with an empty string as name.

    But I'm wondering if this might have some relevance as vulnerability, since I remember seeing sequences of // as special syntax for network resources.

    update

    °) It's possible on win at least, because it translates multiple / to no-ops, hence a//b is the same like a/b

    so I created

    C:\tmp\x\y>echo warn 'inside';1 >z.pm

    started the debugger and ran

    DB<5> use lib '.' DB<6> use x::::y::::z inside at x//y///z.pm line 1.

    It also reveals a trick to force a recompile of a module by adding more :: to the path.

    Like that Perl won't find it cached in %INC and try to require it again.

    DB<7> use x::::y::::z DB<8> use x::::y::::::z inside at x//y///z.pm line 1. at x//y///z.pm line 1.

    DISCLAIMER: Too lazy to test this with linux (shame on me) and the rest of perlport... (no amiga handy...)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      At least on Linux, for existing modules it works as if just one pair of colons was specified:
      main::(-e:1): 1 DB<1> use Time::::Piece;

      But it loads the package that's declared in the file under its correct name:

      DB<2> x Time::::Piece::localtime->ymd; Can't locate object method "ymd" via package "Time::::Piece::localtime +" (perhaps you forgot to load "Time::::Piece::localtime"?) at (eval 7 +)[/usr/lib/perl5/5.26.1/perl5db.pl:738] line 2. DB<3> x Time::Piece::localtime->ymd; 0 '2022-02-09'

      map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
        Our brains are in sync again, see my update for win... ;-)

        I'm wondering if there is an OS-agnostic rule to reduce // to /

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

      I remember seeing sequences of // as special syntax for network resources.

      In Windows // aka \\ is significant at the start of a path.

      • \\server\share
        • \\localhost\c$ (C:\)
        • \\wsl
        • \\server\pipe\name
      • \\?\C:\foo Long path
      • more

      Too lazy to test this with linux

      // is the same as / there.