Squeak 中的 FFI：单例 ExternalLibrary 与类方法与 ExternalStructures 中的方法？答案

【问题标题】：FFI in Squeak: Singleton ExternalLibrary vs. class methods vs. methods in ExternalStructures?Squeak 中的 FFI：单例 ExternalLibrary 与类方法与 ExternalStructures 中的方法？
【发布时间】：2016-12-19 01:12:24
【问题描述】：

我正在为现有库（用 C 编写）编写 FFI 接口。

该库使用了大量的不透明结构，因此我定义了几个ExternalStructures（没有字段）用作void*。

现在我已经看到了与库交互的两种（或四种？）方式：

拥有一个ExternalLibrary，每个导出函数都有一个方法：这可以在实例类中有方法，然后使用单例模式来拥有一个实例。或者使用“更复杂”的语法在类端实现方法，包括 FFI 杂注中的 moduleName，如下所示：

ffiTestFloats: f1 with: f2
  "FFITestLibrary ffiTestFloats: $A with: 65.0"
  <cdecl: float 'ffiTestFloats' (float float) module:'SqueakFFIPrims'>
  ^self externalCallFailed

什么更好？

此外，我还看到了其他方法，根本没有ExternalLibrary，而是直接在ExternalStructure 中实现这些方法。我更喜欢第二部分，但是，所有 FFI 接口定义都分布在几个类中，维护和移植到其他平台、Smalltalk 方言或库版本可能会更复杂。

那么，“正确”的做法是什么？

【问题讨论】：

我不知道这是什么 Squeak 方式，但我喜欢 ExternalLibrary 的方法，每个导出函数一个方法。在 ExternalStructure 中也有方法可能会很棘手，因为某些函数可能有多个结构或根本没有结构。

标签： smalltalk ffi squeak

【解决方案1】：

我会使用ExternalLibrary 方法，因为它允许您自定义库名称，而不是在每个方法中硬编码。

【讨论】：

【解决方案2】：

我会坚持按原样建模事物的传统方法。我们这里有一个外部库，然后让我们为它创建一个类并在我们的对象中复制它的 API，当然，使用执行所需 FFI 调用的实例端方法。

我们已经使用这种方法二十年了，经验表明单例模式在这种情况下非常有效，因为它使客户的生活变得轻松。当然，这个工具必须小心处理，以免您从不适当的地方引用库实例。但是请注意，这不是一个必要的决定，但您必须以某种方式将库的唯一实例保存在某个地方。

在涉及的外部结构中实现 FFI 调用是不自然的，因为某些调用可能涉及多个结构或根本不涉及。那么，你会把它们放在哪里呢？

您还提到了在类方面实现方法的想法。毕竟，我们都同意每个库应该只有一个实例，不是吗？放弃这种可能性的一个原因是类端方法将提供不太灵活的实现。为什么？因为一件事是使用某种机制来只拥有一个类的实例，另一件事是让它不可能拥有它。如果您的对象是一个实例（而不是一个类），您仍然有可能避免明确鼓励对单个实例的限制，并能够创建另一个实例。这将违反您自己的规则，但能够这样做总是更好。想要这样做的一个简单案例是测试。您可以创建第二个实例，该实例连接到另一个版本的库，并在无需修改类的情况下对其进行测试。不选择类端方法的另一个原因更微妙：类代表事物的概念，而不是事物。因此，它们的自然协议不同于它们实例的协议。将两个界面分开将使您的设计更加清晰。

【讨论】：

Gera 只是询问将函数声明放在哪里 - 据我了解，他不想/不需要窥视结构内部。
@BertFreudenberg 好点。我删除了不相关的段落，并添加了一些与问题相关的评论。谢谢！

【解决方案3】：

我更喜欢第一个选项，一个代表外部库的对象，在 C 函数和实例方法之间具有一对一的映射。当然，这是较低级别的抽象，应该在它之上构建更好的抽象。我不会使用“单例”，我认为不需要“类的一个实例”。您需要的是一个众所周知的对象，并且该对象不应直接从内部引用以避免耦合，应在需要时将其作为参数传递。

【讨论】：