其实後来的更新几乎都是乱写了，这次的更新也差不了太多。 大抵上就是增加个 C++ TR1 style 的 bind... 用起来的味道大概是这样：（如果熟 C++ TR1/boost bind 的话，一眼就知道了） assert_equal [9,8,7], ([1,2,3].map &(lambda{|lhs, rhs| lhs-rhs}.bind 10, :_1)) assert_equal [3,2,1], (lambda{|a,b,c| [a,b,c]}.bind :_3, :_2, :_1)[1,2,3] assert_equal [1,9,3], (lambda{|a,b,c| [a,b,c]}.bind :_1, 9, :_3)[1,2,3] assert_equal [9,2,3], (lambda{|a,b,c| [a,b,c]}.bind 9)[2,3] assert_equal [9,4,2], (lambda{|a,b,c| [a,b,c]}.bind 9, :_3)[2,3,4] 不过我总觉得 ludy 应该可以继续走下去才对。所以我想在下次做一次 major update, 版本号大概就是 0.1.0 吧。会做的改变大概如下： 1. 整理 project directory structure, 现在根本就是乱七八糟。 我想大概会用 gem bones 去做吧。其实我是比较 prefer hoe, 但是 bones 的 rake task 有 namespace 比较漂亮... 如果 hoe 会更新到使用 namespace 的话，我再 switch 过去。 现阶段，我想 bones 是个不错的选择。 使用这种东西的好处，当然就是不用去设计 directory structure... 而且自己写 gemspec 老实说也真的是满麻烦的，bones 和 hoe 都有 rake task 帮我 build gem 档，甚至还有 publish, 多方便。 2. 思索 puzzle_generator 的未来。其实他跟 ludy 一点关系 都没有，只是我为了使用 svn server 所以才把他加到 ludy 上的。 到底 puzzle_generator 应该分出来，还是在 ludy 中找到一个位子？ 分出来的话，又该分去哪里？ 3. ruby 1.9 compatibility, 我刚刚稍微测试了一下，有几个比较脏的东西 在 ruby 1.9 是跑不起来的。这个应该要想办法修掉，ruby 1.9 很棒的。 除了效能好很多以外，多了很多我想要很久的功能，能早点转过去就早点。 可惜的是 1.9 问题还很多，而且很多 gem 没办法在上面跑，所以 1.8 还是必备的。 现阶段会让 1.8 和 1.9 都相容，等 1.9 够稳了，就不会考虑支援 1.8 了。 4. require path 的麻烦问题。去看看 facets, 他们对於 require path 大概 也很头痛吧。从 2.0.0 就整个把 require path 翻修过，结果还有大 bug, 害我完全没办法用。果然很快就推出 2.0.1 了...。还是 2.0.1 ~ 2.0.2 的阶段， 我忘了。反正就是很可笑的状况，名称冲突之类的。bug 期间我是暂时 monkey patch. 再看看 rubygems, 一开始有个 require_gem. 而我，却也弄了个 require_ludy. 没办法，因为很难写一个在任何情况下都有效的 require, 所以才搞出那种东西。 但是现在我觉得，还是应该多为 user 想想，毕竟连 rubygems 都舍弃 require_gem, 我也不该继续使用 require_ludy 才对。 无奈这真的是个很大的问题，可能势必得做得不要那麽 general 吧？大致问题如下： a. 使用 gem install 时可以正常 require. b. 把东西全部 copy 到 project path 时, 让 -I 可以 work. 其实简单地说，就是希望不要 gem install 也可以轻松放到专案中使用。 不过也许得放弃这个要求吧？因为实际在写时，就会发现很多问题都跟这有关。 如果能「假设」gem 一定有安装起来的话，很多考量就可以不用做了。 事实上，不需要安装 gem 也能 work, 对於开发也很有用。因为我可以改改程式 就测试最新的结果，而不必自己装一份。所以，还是再看看吧。还是希望能有好方法。 5. unit testing. 既然是 unit testing, 当然就要有能够分开 test 的动作。 我希望可以 ruby test/tc_bind.rb, 也可以 rake test 测试所有的 unit test. 之前因为没在用 rake, 我自己写了个 ts_ludy.rb, 大概就是做这件事。 所以 ruby test/ts_ludy.rb 就可以跑所有的测试。 而我发现，如果照 unit test 原先的设计，把所有东西都 require 起来再跑， 执行效能会变得很烂很烂。原因我不是很清楚... 所以後来我改变作法， 变成一个个去跑每个 unit test, 然後把输出结果蒐集起来，再报告出去。 这样的好处就是跑得速度真的快太多了，好几倍的差别。缺点当然就是， 这样做挺诡异的... 所以关於 testing 的部份，也还需要再整理一下。大致就是希望能单独跑也能一起跑。 另一方面，我要求 testing 所使用的 lib 应该要是相对路径下的，而不是 gem 上的。 理由同 require path 上面的描述。 其实对於 require path 和 unit testing 的部份，我花了不少功夫， 不过成果其实还满差的。当时看是没什麽感觉，现在看觉得实在很丑。 6. 去掉 shebang, 那很蠢。（那时候对 shell 太不熟了） 7. ludy_ext.rb 这东西，本来是想放各个没在 Ludy module 下的东西，不过这样成长太恶心了。 应该学学 facets, 一个 method 一个档才对。所以这部份也要切开，整理一下。 8. 整合之前为了 shooting-cubes 做的一些 rake task, 还有 erb meta-programming 的一些相关 method. 这个， 和 puzzle_generator 一样好像有点尴尬，不太属於 ludy 的范畴。 不过在整个 ludy 东西还很少的状况下，我希望尽量整合一些 lib. 9. 尽快整合 multi, 那个 multi-method 的 lib. 我在想，我可能自己实作一份，就不要直接把他吃进来。 multi 是 MIT license, 我想我直接吃进来应该没问题， 只是整个感觉就很怪，而且他的程式有些部份我不太满意， 所以也许我自己做一份还是比较好，这样也不用想怎麽合并。 如果确实做出来了，那大概就只留一份 NOTICE 或感谢之类的， 就不保留原本的 require path 了。不然，我真的觉得那样很丑， 像是分裂的个体似的。 10. 修改一些文字说明，包含 README, CHANGES, description 之类的。 现在的格式已经有点接近乱写了。另一方面，也希望稍微修改一下 rubyforge 上的 release 结构。 11. 撰写 rdoc, 完全没 doc 其实也有点奇怪... * 所有的 source code 都采用 Apache License 2.0, 希望下次的更新可以涵盖以上几点。 btw, bind 实作只有 13 行（含注解） 安装： gem install ludy 取得所有程式： svn checkout http://ludy.rubyforge.org/svn/ or svk mirror http://ludy.rubyforge.org/svn/ //mirror/ludy -- Hear me exalted spirits. Hear me, be you gods or devils, ye who hold dominion here: I am a wizard without a home. I am a wonderer seeking refuge. Sacrifice --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.135.28.18