duangsuse::Echo
val r = >>> val r = Feeder.of("Hell") >>> r.consume() H …… >>> r.consume() l >>> r.consume() StreamEnd(position=5, max=3) at StreamKt.eofError(Stream.kt:7) at Feeder.checkIsEOS(Feeder.kt:34) at Feeder.access$checkIsEOS(Feeder.kt:9)…
我算一下：['H', 'e', 'l', 'l']
迭代 consume() 到第一个 l 是（这就是说 Feeder 有点真正意味『peek1』的意思了）
（我之前还打算支持 Stream 来着，不过到底也就是
（我讨厌分析型变，尤其是，不过我看了 #Java #Gradle 插件们的一大堆高*哦不是自豪感爆棚…… 声明处型变是哪些个地方……）
所以请容许我在这里再次强调： Java 是辣鸡
是 position=3，接下来的一位是最后一个 l
然后此时 position=4，还没有 consume() 消耗掉它
接下来 position=4，此时不应该有 next，不过依然有一次机会
然后 consume() 调用 s.next()，position=5（因为我们一律是先自增 inc()，再索引，所以无论如何也会自增……），失去第一次保持机会（FinalConsumeIter）
不行，这看起来是太荒谬…… 虽然
我们的自增（当然这个比较麻烦）表达式
不过这毕竟是『Peek』流，虽然我没暴露编程接口，负责的方法是把原来（其实也涉及到接口本身偏向应用化的原因）改的东西改回来
我怎么感觉
感觉很不对称，没办法，只能用这种方法解决，应该是那种理论上给人的无力感……
迭代 consume() 到第一个 l 是（这就是说 Feeder 有点真正意味『peek1』的意思了）
（我之前还打算支持 Stream 来着，不过到底也就是
PeekStream<out E>……）（我讨厌分析型变，尤其是，不过我看了 #Java #Gradle 插件们的一大堆
Action<? super T>，我瞬间所以请容许我在这里再次强调： Java 是辣鸡
是 position=3，接下来的一位是最后一个 l
然后此时 position=4，还没有 consume() 消耗掉它
接下来 position=4，此时不应该有 next，不过依然有一次机会
然后 consume() 调用 s.next()，position=5（因为我们一律是先自增 inc()，再索引，所以无论如何也会自增……），失去第一次保持机会（FinalConsumeIter）
不行，这看起来是太荒谬…… 虽然
xs[index++] 看起来更好看，我不能允许暴露的细节也这样……我们的自增（当然这个比较麻烦）表达式
(index++) 是在结果为原来值的基础上顺便更新左值，所以应该不会有太多问题，这个问题是我的实现会至少多调用一次 next()，导致索引失真不过这毕竟是『Peek』流，虽然我没暴露编程接口，负责的方法是把原来（其实也涉及到接口本身偏向应用化的原因）改的东西改回来
我怎么感觉
peek xs = zip xs (drop 1 xs) …… 或者是别的方法，因为 1 就不能 peek 了？感觉很不对称，没办法，只能用这种方法解决，应该是那种理论上给人的无力感……
> Configure project :
Kotlin Multiplatform Projects are an experimental feature.
> Task :compileKotlinJvm
> Task :jvmProcessResources NO-SOURCE
> Task :jvmMainClasses
> Task :compileTestKotlinJvm
> Task :jvmTestProcessResources NO-SOURCE
> Task :jvmTestClasses
> Task :jvmTest
BUILD SUCCESSFUL in 11s
3 actionable tasks: 3 executed
17:20:59: Task execution finished 'jvmTest'.
一看到 All Passed 兴奋的
我该去吃饭了，呼。
啊不对，已经九点了，我好像没吃晚饭
艹，说不定超市已经关门了
这么晚不吃饭吃零食会不会长胖
（反正我也很瘦…… 怎么个受瘦法呢，上面的那一张里齐景轩很瘦，就体型来说我和他一样瘦…… 艹）
啊不对，已经九点了，我好像没吃晚饭
艹，说不定超市已经关门了
这么晚不吃饭吃零食会不会长胖
（反正我也很瘦…… 怎么个
马上开源来的
明天可以写基于它们的解释器（虽然 RingBuffer 是凑数的（其实没有凑数的，都 TMD 是我的心血啊！！！
可是我不想写，虽然很简单
可是我觉得也有必要写，可是没时间了，艹 *3
其实我觉得 Parser.kt 的一部分代码，写出来都会很有意思，体积不知道怎么样，应该没问题
明天可以写基于它们的解释器（虽然 RingBuffer 是凑数的（其实没有凑数的，都 TMD 是我的心血啊！！！
可是我不想写，虽然很简单
可是我觉得也有必要写，可是没时间了，艹 *3
其实我觉得 Parser.kt 的一部分代码，写出来都会很有意思，体积不知道怎么样，应该没问题
我不知道是因为时间太少、还是任务太多、还是上机的时间太珍贵、还是我自控力差，为什么我第一次有这种看瞎眼的感觉？我开了红移(redshift)…… 🤔
This media is not supported in your browser
VIEW IN TELEGRAM
这可是我的血汗码，得加上 GPLv3，不能让妮妮萌萌之类的光明正大拿去抄了，艹
有一个方法是写测试（持续开发持续测试持续集成…… 你可以利用面向对象多态 moke 模拟对象，或者是像 Aqullian 测试组那本 CEDJ Java 书一样，真实在本地自动部署测试环境执行测试），还有一个更好的方法是不写 bug，当然这个是那些欠打的 Haskell 程序员说的，他们连 syntax error 都不屑给你指出。
当然对我来说，我觉得任何应用程序都是不应该写测试的（因为他们不应该能够让你写错代码，无论是从工具的角度还是文档的角度）；绝大部分算法和框架的测试都应该可以用 Haskell
文档懒得读可以尝试和作者从一个角度想问题，而不是被动接受别人的解释，比如：
当你看到 gradle 的
当你看到
当你写复用库的时候，应该从用户的角度看问题，比如：你要定义一个
此时，你发现这个 (getter) 方法是纯函数，它没有副作用，所以你定义
很多其他情况你考虑一些诸如『是不是提供 vararg？』『是不是用
当然对我来说，我觉得任何应用程序都是不应该写测试的（因为他们不应该能够让你写错代码，无论是从工具的角度还是文档的角度）；绝大部分算法和框架的测试都应该可以用 Haskell
Test.QuickCheck 的方法来写。文档懒得读可以尝试和作者从一个角度想问题，而不是被动接受别人的解释，比如：
当你看到 gradle 的
from 时，你会想到：我在 task 里用 from 是什么意思呢？task 是将多个文件汇编成一个文件，所以 from 是指定一个输入的意思当你看到
task (type: ...), Task.dependsOn 的时候也会从使用对象工作流程本身的视角看问题当你写复用库的时候，应该从用户的角度看问题，比如：你要定义一个
Collection<*>.isNotEmpty，是要把它作为扩展方法还是扩展属性？此时，你发现这个 (getter) 方法是纯函数，它没有副作用，所以你定义
val Collection<*>.isNotEmpty: Boolean get() = size != 0 很多其他情况你考虑一些诸如『是不是提供 vararg？』『是不是用
Builder？』『这个 out 是什么意思？』的时候一样有效