LlamaKit 0.6.0

LlamaKit 0.6.0

测试已测试
语言语言 SwiftSwift
许可证 MIT
发布最后发布2015年4月
SPM支持 SPM

Ash Furrow 维护。



LlamaKit 0.6.0

LlamaKit

必备功能工具集合。试图尽可能轻量,希望提供一个简单的基石,以便更高级的系统可以在此基础上构建。LlamaKit 非常注重 Cocoa。它被设计用于与常见的 Cocoa 架构协同工作,使用 Cocoa 开发者易于理解的命名方式,与 GCD 等Cocoa 工具集成,并且总的来说,为了使熟悉 Objective-C 和 Swift 的开发者(而不是 Haskell 和 ML)有较低的到适中的学习曲线而努力。世界上有更多的功能丰富的工具集(例如,参见 SwiftzSwift-Extras 中的一些示例)。LlamaKit 故意具有较少的功能完整度,并且仅关注 Cocoa 开发中常用的东西。(在这些限制内,它期望尽可能多地在其他函数式编程语言的教训之上,并且欢迎有更深入函数式编程经验的人提供反馈。)

目前拥有一个 Result 对象,这是最重要的。(最终,它可能是主模块中的 唯一 一个。)Result 对象大部分已经完成,除了文档(正在进行中)。测试也已完成。

Future 正在进行中。它深受 Scala 的方法 的启发,尽管有一些小的不同。我还没有决定 Promise 是继承自 Future 还是包含 Future。Scala 方法是一种奇怪的混合体。从技术上讲,它包含 Future,但在主要实现中,Promise 是它自己的 Future,所以它也有一点继承的感觉。那个仍然是正在进行中的工作。我在考虑将 Future 提出来;它已经使这个模块过于复杂(我提到过 LlamaKit 希望非常简单,对吧?)

LlamaKit 应被视作高度实验性的,预 alpha,开发中,我承诺我会让你的应用崩溃。

但如果你想要使用它,Result 对象已经不错了。 :D

对结构当前的想法

(这正在进行中并且可能会发生变化,就像 everything 一样。欢迎评论。)

我希望 LlamaKit 提供一些重要的工具来简化函数式组合。但是,LlamaKit 并不打算成为一种编程方法(与提供强大问题思考方式的 ReactiveCocoaTypeLift 相比)。LlamaKit 只是工具包中的工具。如果你想借我的锤子,不必也拿走我的圆锯。所以 LlamaKit 被分成几个小框架,这样你可以挑选你想要的。

LlamaKit (总框架)
LlamaFuture 羊驼…(?) LlamaOps
LlamaCore

LlamaCore:基本绝对。如果它在LlamaCore中,我相信大多数Swift开发者都应该使用它。我认为其他库应该在此基础上构建。我认为苹果应该将其放入stdlib。这是我担心许多开发者会重新发明并导致代码库之间冲突的地方。LlamaCore力求影响极小。它避免创建可能与使用代码冲突的顶层函数。它不声明新的运算符。进入LlamaCore的门槛非常高。它目前只包含两种类型:ResultBox(仅因为Swift编译器限制而存在)。在理想的LlamaKit中,LlamaCore将是空的。

LlamaFuture:并发原语,最重要的是Future。在我的当前设计中,Future实际上是独立的,不需要LlamaCore,但我认为大多数开发者将需要失败的Future(我暂定为Task)。我也预计这还将包含Promise,它是一个由调用者手动完成的未来。(这还在非常严重的考虑中;我不确定我到底想要什么。)LlamaFuture与GCD紧密耦合,旨在提供比常见Cocoa并发原语更友好的界面,而不是取代它们。

LlamaOps:使用>>=|>等运算符的功能组合是一件事非常漂亮。但它伴随着很多开销。不仅有认知负载(对初学者来说,代码一点也不明显),还有非平凡的编译器和语言影响。运算符被全局声明的(特别是优先级和结合性)。Swift编译器在构建复杂运算符使用代码时有一些严重的性能问题。而且,在运算符冲突的情况下,导致的错误非常令人困惑。广泛使用的库应强烈避免隐式引入新运算符。我的意图是,你必须始终显式导入LlamaOps,即使导入的是伞形框架LlamaKit。

LlamaKit:我确实希望LlamaKit中的许多东西对大多数甚至所有Cocoa开发者来说都有用。我不想强迫你接受一切,但我确实想让你容易地接受一切(除运算符外)。所以,我希望我能够提供一个伞形框架。我不知道这实际上在Xcode中是否有效,但我们拭目以待。

Llama…:在此阶段,我不期望有更多东西,但这是它的去处。当我在推广函数式编程时,我希望大多数人使用Swift来实现,而不是在Swift之上添加很多层。所以例如,我现在并不特别看好Either。在大多数情况下,我更愿意你直接使用枚举。而且,我不想创建一个完整的functor-applicative-monad层次结构(TypeLift为我们提供了这一点)。我可能确实想要一个地方放置sequence()lift()pure()flip(),也许它有可能成为LlamaLambda(LlamaLamb?LlamaFunc?)。但我想要慢节奏地这样做,看看实际项目中的需求是什么。