在不牺牲常规工作流程的情况下进行优化：参数、POD 等

Question

https://martimm.github.io/gnome-gtk3/content-docs/tutorial/Application/sceleton.html , 缩写:

In Raku, it is important that the main program is kept small. This is because all code, program and modules are parsed and compiled into an intermediate code which will be executed by a virtual machine. Most of the time that will be MoarVM but there is also a JVM and later possibly others. Anyways, before running, the compiled modules are saved into .precomp directories but not the program. This means that the program always get parsed and compiled before running and that is the reason to keep it small.
use UserAppClass;

my UserAppClass $user-app .= new;
exit($user-app.run);
Well, you can’t get smaller than this …, or maybe use this one-liner; exit(UserAppClass.new.run).

The rest of the code is defined in the UserAppClass.

很好。

现在，我们的程序需要接受参数。 sub MAIN 解析参数并免费生成 $*USAGE，因此我们将利用 sub MAIN.
我们通过 .raku 程序 .rakumod 将 sub MAIN 放入 used，但我们得到的 .raku 程序不知道参数。并且 sub MAIN 在模块中时不会执行。
我们把sub MAIN放到.raku程序里，让它能理解参数，但它不再小了。
此外，程序的嵌入式 POD 可能预计驻留在 .raku 程序中。
通过 .raku 程序 .rakumod 将 POD 放入 used 中，我们得到 POD 有点隐藏。
把POD放到.raku程序里，又不小了
此外，这种方法是否有任何命名约定？
比如说，你有一个程序 Report when your coffee is ready。它的sub MAIN在coffee-ready.raku，你use一个QueryCoffeeMachine.rakumod.
您更改了文件的布局，现在对于同一个程序 Report when your coffee is ready，您有一个 coffee-ready.raku 启动器、一个具有 sub MAIN 功能的 coffee-ready.MAIN.rakumod 和一个 QueryCoffeeMachine.rakumod.
我相信 QueryCoffeeMachine.rakumod 保持完整，
我觉得 coffee-ready.raku 尽管更改了内容
也应该保留名称但是 coffee-ready.MAIN.rakumod 应该如何命名呢？

Answer 1

Anyways, before running, the compiled modules are saved into .precomp directories but not the program.

Aiui 有人可以将预编译扩展到主程序文件，但是对于核心开发人员来说它的优先级较低，因为可以使用如下解决方案解决它：

... sub MAIN is not executed when in a module.

如果你export/import进入主程序，模块的MAIN会在你运行主程序时执行：

# MAIN.rakumod
our sub MAIN (Int $int-arg, Str $str-arg) { $int-arg }

# main.raku
use lib '.';
use MAIN;

... we get the .raku program ignorant of the arguments

如果你在主程序中wrap导入了MAIN，你就会知道参数：

# main.raku
use lib '.';
use MAIN;
&MAIN.wrap: -> |args { say args; callsame }

（如果在 CLI 传递的参数与从 MAIN 模块导入的 MAIN 子程序的签名不匹配，则会显示用法消息。否则 main.raku 被调用并可以用传递的参数做它想做的事情，并决定它将如何调用导入的 MAIN。）

（我从中提取了这个解决方案。）

Put POD into a ... .rakumod and we get the POD somewhat hidden.

我不知道现有的方法可以避免这种情况。（也许检查 Access POD from another Raku file 以了解如何至少访问另一个文件中的 POD。）

也许一个新的问题只关注那个方面？

how should .MAIN.rakumod be named?

如果是我，我可能会想到一个 Coffee-Ready 文件夹，然后在其中有一个 coffee-ready.raku、一个 MAIN.rakumod 和一个 QueryCoffeeMachine.rakumod.

在不牺牲常规工作流程的情况下进行优化：参数、POD 等

Optimize without sacrificing usual workflow: arguments, POD etc

optimization

main

command-line-arguments

precompile

raku