I'm looking for some cleanup of my knowledge. Within a project with complex module structure I'd like to keep the structure clean by building up structured namespace tree. Say, something like:

App
Config
Key
Node
Param
Type
MyType

Every entry under App::Config shall be contained in its own file. Always typing things like App::Config::Key is a time waste. is export doesn't have a parameter to declare the name which is to be exported. So, I finally came to the following solution:

Config.pm6:

unit module App::Config:ver<0.0.1>;
...

Key.pm6:

unit package App::Config;
class Key is export {
...
}

And it works as I want it:

use App::Config::Key;
say Key.^name; # App::Config::Key

The only question remains: a there any caveats? Any hidden side effects to know about?

The only thing I can think of right now, is that you should not make the class a my if you want to ensure any .perl output will round-trip. It will default to our, so if you don't specify anything, you should be find in that respect.
– Elizabeth MattijsenJan 17 at 9:27

1

Only thing I can think of is related to documentation. You will need to know in advance that in order to get to the documentation of Key you need to look up App::Config. Also, documentation of the class itself. It might not be obvious, looking at the file structure, what classes are there available. None of them is a big deal.
– jjmereloJan 17 at 10:53

@jjmerelo, do I get you correctly that p6doc App::Config::Key will have trouble finding the docs in App/Config/Key.pm6 in this case?
– Vadim BelmanJan 17 at 14:26

4

Ok, it seems like exporting roles from packages doesn't work the way it should. The short name is available, it is applicable to a class. But when tested for .^does (or ~~ for that matter) the short names fails the test whereas FQN passes it ok: for class Foo does Role { ... } check Foo ~~ Role === False but Foo ~~ App::Config::Role === True. Would have to report the issue.
– Vadim BelmanJan 17 at 19:05