问题标签 [moose]

处理构建器方法失败的最佳方法是什么？

例如：

如果_build_file_handle未能获得句柄，则构建器将返回undef，这将导致类型约束失败。

我可以在类型约束中使用联合file_handle，以便它接受一个undef作为有效值。但是，谓词has_file_handle将返回 true，即使值为undef.

有没有办法发出构建器失败的信号，并且属性应该保持清除？

我正在编辑使用 Moose 的包，我想知道是否有一个插件可以让 Moose 属性显示在标签列表中。

例如，在以下代码中，该属性options不会显示在 Tag_List 中，但print_out_site会显示：

与 Moose 一起使用时，是否可以让 Log4perl 正确显示日志事件的行号和包/类，而不是始终在第 99 行显示 Method::Delegation？

在我的例子中，我创建了一个属性 isa Log::Log4perl::Logger 并将各种日志记录级别委托给我的类（日志、警告、错误......）。这样做还会将Delegation.pm 显示为文件。

谢谢！

考虑这个简单的类：

然后这段代码：

代码以关于类型约束失败的大错误消息而终止。

我希望能够提取失败的属性（foo）、原因是什么（失败的类型约束）以及传递的值是（Not an Int），而无需解析错误字符串来获取信息。

像这样的东西：

这可能吗？有没有一个 MooseX 发行版可以做到这一点？更好的是，是否有一些我错过的 Moose 功能可以使这成为可能？

更新：我对类型约束特别感兴趣，但其他 Moose 错误也会非常好。我也知道我可以用die. 因此，在我编写的代码中构造异常相对容易。

我有一个角色和几个混合角色的类。Role 类加载所有实现类，以便任何导入 Blah 的东西都可以使用它们，而无需键入很多“使用”行。

一个典型的 Blah 子类：

由于每个子类 'foo' 方法都以相同的代码位开始，因此角色也通过方法修饰符实现这些。

问题是：Moose 没有将方法修饰符应用于任何 Blah::* 类。即使我删除了类的 make_immutable 调用，也会发生这种情况。我认为角色应用完全是在运行时完成的，所以即使在 Blah 之前加载了 Blah::* 类，仍然应该应用修饰符？

我正在寻找解决方法，或另一种做事方式。目前 Blah 本质上是一个抽象基类，除了方法修饰符，这就是为什么我一开始就使用角色 - 但也许类层次结构会更好？提前致谢。

我想开始严格地进行测试驱动开发。但是，我想知道我应该测试多少 Moose 和 MooseX::FollowPBP 生成的方法。例如，我有以下课程：

我当前的测试脚本是：

这是足够的还是过多的测试？（也就是说，除了明显缺失的正则表达式测试）。

我以为我在某处看到了有关此问题的网页或其他帖子，但今天找不到。

上我的 Moose 课似乎有点痛苦。然后使用DBIx::Class获取结果集..然后手动将我的结果集映射到 moose 类。

Moose::Manual::MooseX的当前版本 (0.98)是以下行：

我们对 MooseX::Method::Signatures和 的未来寄予厚望MooseX::Declare。然而，这些模块虽然经常被社区中一些更疯狂的成员用于生产，但仍被标记为 alpha，以防万一需要进行向后不兼容的更改。

我注意到2009 年 9 月MooseX::Method::Signatures的更改日志提到删除了“可怕的 ALPHA 免责声明”。
那么，这些仍然是“阿尔法”吗？
我还会被认为是使用它们的“更疯狂”的人之一吗？

有很多关于MooseX::Method::Signatures的讨论，甚至在此之前，Params::Validate等模块旨在对方法或函数的每个参数进行类型检查。我正在考虑将前者用于我未来的所有 Perl 代码，包括个人和工作场所。但我不确定这是否值得努力。

我在想我之前看过（和写过）的所有 Perl 代码都没有执行这样的检查。我很少看到一个模块这样做：

也许是因为没有某种辅助模块，工作量太大，但也许是因为在实践中我们不会向函数发送过多的参数，也不会向期望标量的方法发送 arrayrefs - 或者如果我们这样做，我们有use warnings;并且我们很快就听说了——一种 鸭子打字方法。

那么 Perl 类型检查是否值得性能打击，或者它的优势主要体现在 C 或 Java 等已编译的强类型语言中？

我对任何有编写使用这些模块的 Perl 经验并看到使用它们的好处（或没有）的人的答案感兴趣；如果您的公司/项目有任何与类型检查有关的政策；以及类型检查和性能方面的任何问题。

更新：我最近读了一篇关于这个主题的有趣文章，名为Strong Testing vs. Strong Typing。忽略轻微的 Python 偏见，它本质上表明类型检查在某些情况下可能令人窒息，即使您的程序通过了类型检查，也不能保证正确性 - 正确的测试是确定的唯一方法。

我是 Moose 的新手，正在尝试将它与 DBIx::Class 一起使用。找到基本的 DBIC 查询和更新工作，但是当我修改属性时，我尝试编写的任何触发器都不会执行。

我希望看到 'isin' 打印 'FOO' 的触发器，但没有任何反应。如果我从包中删除 DBIx::Class 触发器将按预期执行。

我怀疑 DBIx::Class 设置值的方式会阻止触发器触发。

不幸的是，我没有找到关于将 DBIx::Class 与 Moose 一起使用的资源。我所写的内容主要基于我在DBIx::Class 和 Moose中找到的内容。

我使用 DBIx::Class 和/或 Moose 错了吗？我应该与 Moose 一起使用不同的 ORM 吗？

带有不会触发的触发器的包：