Ruby Tuesday #11 (3)
經 ihower 的 push, 把投影片放上 slideshare 了
我後來發現還有影片哩。
不過速度超慢的，要看完恐怕會很辛苦吧...
我是用 wget 砍下來了 -_-
==
今天總能早睡了吧？關機
還有仔細想想，我真的很刻意地忘掉很多事了
但能這樣說其實很諷刺
看明天能不能早起把今天沒弄完的弄完
Showing posts with label 投影片. Show all posts
Showing posts with label 投影片. Show all posts
2010-04-14
Ruby Tuesday #11 (2)
上一次講得確實是有點亂，我想這一次應該有比較好？
一方面是這次投影片雖然也不算有完全完成，但至少是完整得多。
當然這跟講得順不順沒有直接關係，但至少表示準備得充分否。
再另一方面則是概念的東西向來比較難講，這次幾乎完全是講實作細節，
那就很簡單看程式碼講話就好了...
中間特別亂的部份應該是 env['async.callback'] 那段，
我想是因為我沒替這部份做投影片，就變得有點抽象...
應該要有白板的，哈哈。再則是有些細節忘記了，
因為其實不是很熟悉，邊看程式碼邊理解的。幸好後來想起來了。
說真的，108p 很多都是一秒不到就帶過，大部份都是 copy pasta,
但我可能花超過 24h (超過三天) 在做這投影片... 可能有點誇張，
因為上色真的很花時間啊 @@" 而 keynote 對於上色這種事，有點麻煩...
我又很龜毛希望每一個顏色都要一樣，就常常在用滴管。
雖然實際上最花時間的部份，應該是閱讀程式碼和文件，試著理解其架構吧。
投影片做得很累，有時候做到很懶得做，畢竟是要撥出自己的時間，
有時候很累了，卻還要硬著頭皮一直看一直做，會覺得很煩。
但有時候做到一定程度，好像熱身完了，又覺得很有趣停不下來，
想把所有看到的東西都放上投影片... 結果就是做到 108p,
也講超過一個小時吧？
rubinius 那次是 135p, 不過動畫更多，實際的量或許比這次少。
但做投影片的時間，全部加起來應該是超過這次 XD
光那張 ruby object model cloud 就做不知道多久了 XDDDD
先是找畫圖軟體，最後找上 UML 的軟體，而且把那個架構試出來，
也很花時間。最後真的講到時，兩三下就帶過 XD
畢竟那種東西細細講來，大概所有人都會睡著吧...
結果變成只為了一個效果，花了絕大多數的時間 XD
沒記錯的話，那次幾乎是一氣呵成，全部看完一次做好。
不像這次，畢竟主題比較分散，就等於是一段一段做了。
於是心裡在想，其實我只是喜歡做投影片吧？ -_-
昨天做完時，就覺得好像一切都結束了 XDD
然後就希望看誰能把這東西，以更清晰的脈絡幫我講出來...
當然這有困難啦，可能還是要做投影片的人自己講吧。
*
不知為何，可能是因為陣仗有點大的關係？ XD
時間快到之前，開始覺得相當不安與緊張，
不是很想吃東西... 一方面會想先講，這樣等會才能輕鬆地
不管是聊天或是仔細聽，甚至是想自己的事或是單純上網。
但另一方面也會希望能夠後講，因為這樣不小心講太久的話，
比較不會耽誤到其他的議程。可以慢慢把比較重要的東西講清楚。
有趣的是，正式開始講時，反而沒什麼感覺。腦裡一邊思考脈絡，
或許可以看成一種 buffering... 然後透過聲帶與喉嚨的 i/o,
試著把不會太過凌亂的東西，以 linear 的方式帶出。
可能是因為這樣就很忙碌了，就沒辦法再顧慮到其他的事情。
當然，這也有一個先決條件，就是脈絡需要足夠清楚吧。
看著自己大概前後翻過，在心裡順過流程的投影片，
很自然就會想到應該怎麼表達這樣的東西。儘管當場會想到，
還有說出來的東西，跟在做的時候，往往並不相同，
大概有一半會遺漏，然後另外補上一半現場瞬間想到的。
比較慘的是 XD
有幾段我想到應該對照上面的某一張投影片，瘋狂往前翻，
講完之後到下一張，才發現自己本來就把那張複製到下一頁了。
如果我剛剛有先按下一頁的話，就會發現根本不用往前翻。
這時候就會有某種分離感，好像過去的自己在笑現在的自己，
瞧，早就準備好了不是嗎？當然這個笑，或許有點微妙吧。
*
總之很順利地結束了，感謝所有的人。也很感謝各個提問與討論，
才能夠適時地想起、修正，還有補充一點其他人有興趣的項目，
而不只是我有興趣的部份。投影片在這：
Reactor Pattern & Event-Driven Programming 2
==
後來不知為何，覺得肚子很不舒服，一路皺著眉頭搭捷運回來了。
想睡到爆炸，把一些本日剩餘一些有時間性的東西處理完後，
準備要關機睡覺時，才想到忘記打這篇 XD 不先打完的話，
明天以後很可能就會有所遺漏，甚至是打不出來了。
我因此而漏打的東西，已經太多了 XD 看看那一堆只有 (0)
卻沒有 (1) 或是本來應該要有 (2) 的那幾篇啊。
雖然又變得很晚睡了，但值得高興的是，肚子覺得沒事了吧 -_-
還有一定很好睡...
2010-04-12
Ruby Tuesday #11
cross posted from 嵐達網
明天是 Ruby Tuesday #11, Ruby Tuesday 是 Ruby 固定在星期二的聚會，
通常會邀請兩個人各講一個簡單的主題。
這次由 tka 聊 Rails integration testing using cucumber+webrat+selenium
和 godfat 聊 Ruby Tuesday 2010 首場裡沒講完的
Reactor Pattern & Event-Driven Programming 續集。
這次補充的項目是：
1) how Thin works
2) how EventMachine works
3) how AMQP works
4) how Unicorn and Rainbows! works
2010-02-13
Ruby Tuesday (02-09)
投影片這裡下載..
Reactor Pattern and Event-Driven Programming
好笑的是，我完全忘記有消失的那一個禮拜，
因此本來以為時間足夠的狀況，忽然變得完全不足 XD
也雖然帶著電腦去，但卻也在飛機上才準備了草稿。
畢竟平時其實滿累的，還要再弄投影片很傷神傷體力 @@
大概到一半的時候，就決定放棄了。回程飛機上再說吧。
這樣就輕鬆多了 ._.
後來大概就是把草稿擬完這樣。就是大綱和一些說明文字。
接著正式做投影片，本來是想找一套 text based 的，
例如之前在試 slidedown, 用 markdown 做投影片，
輸出 .html 檔，用 jquery 翻頁。
但是後來不打算用這套，一方面是覺得做得不太完整，
另一方面則是我找不到控制字體大小的方式？生出來的字很小啊。
在想，或許要確保比例正確的話，一定需要一個基準吧？
理想上，或許就是我們可能會有個基準，例如 1280*768
然後是向量格式，可以任意縮放之類的...
時間太趕，因此就決定直接用 keynote 就好了。
其實 keynote 對於要做簡單的投影片來說，
是還滿方便的。雖然我不太喜歡 duplicate 的方式，
而且填色也不是很方便，他不會記憶我上次選的顏色。
所以我必須一直用滴管去取上次選的顏色...
不過大抵上來說操作是滿直覺的，尤其是他動畫的部份。
基本上我想要的結果，居然隨便試一下就試出來了。
還真的支援從任意 paragraph 開始動，細節也能調。
我對於 power point 不太有印象了，那是好久以前的事。
但記得是比 open office 裡面的東西好用多了...
看到 open office 做成這種樣子，有時候在想，
或許這些超複雜的軟體，還是只有商業公司才能做？
尤其是 UI design 啊...
總而言之，做了一整個晚上，還沒做完 XD
而且有些地方想把圖畫好一點，應該也沒時間做。
想到這裡，就覺得乾脆弄成待續也沒什麼不好，
至少下次可以做完整一點。（然後次日真的請假了 XD）
*
這次是覺得不錯啦，我是說整個活動給我的感覺。
或許有趣的是，往往會擔心有那種不適感，
但通常會這樣想時，最後結果都是比想像中好很多。
真正會有那種感覺的狀況，我猜打從一開始就不會考慮吧？ XD
雖然有時候不是能夠選擇的。
至於 talk 的檢討嘛...
去除一些比較客套的說詞，或許還勉強可以吧？
台風的問題是不怎麼放在心上，可能因為多少有點經驗了？ XD
內容就覺得有點慘了，覺得非常容易弄成懂的都懂，
但不懂的卻仍然只看得到朦朧的概念。
最主要的問題，我想是因為在講的時候，我的視野很容易
就變成很小，因此很難把 overview 帶出來。
投影片基本上只是輔助，光看投影片，並不容易帶出整個
overview. 畢竟我並不喜歡鉅細靡遺的投影片...
結果就是會不斷在各種小細節裡面跳躍。
而這次的題目，其實說穿了也沒什麼，
結果就變成不斷跳躍，因為小細節是真的很小 @@...
我想我大概還是比較適合做靜態的事吧我猜 XD
不然就是要講前先寫成文章，或是講稿之類的。
我臨場反應不夠快，沒辦法邊看邊講邊組織。
有時候為了不要掛在投影機上，也會亂跳主題，
因為想到什麼就講什麼...
以台風來講，是比卡住要來得好啦。
但有在聽內容的話，應該會覺得很混亂... XD
*
跟上次 rubinius 比起來嘛。
我想應該是因為比較簡單，或是說這主題懂的人比較多，
因此比較有迴響一點。但就印象來說，
我覺得上次應該講得比較好？ XD
至少亂跳的情況比較少一點。
應該跟主題有關就是了。
2010-02-09
2010-02-08
back in T (0)
肯定會變超級 murmur 加上流水帳，but i just
want to throw some random thoughts.
i think this may reflect my mind i guess...
約 02-01 的凌晨五點從家裡出發，搭七點多的飛機，沒記錯的話。
回來時也是 02-07 的凌晨五點左右... 因此基本上日期上是七天，
但實際上只有五天左右。畢竟第一天抵達時也晚上九點多啦。
有趣的是，去時覺得飛好久，坐到後來都覺得不太舒服。
而回來時，卻專心在準備 ruby tuesday 的 talk,
回過神時已經去掉四個多小時了吧？這台小 laptop
確實滿省電的，大概只用掉 50% 電力。照這種用法，
我看還真的能用到八小時也說不定。
我的用法大概就是用 firefox 看網頁（抓下來的 html），
用 cygwin 的 vim/less 看 ruby source code,
還有用 notepad++ 編輯 slide 的 draft.
windows 7 的畫面效果則全關，用傳統模式。
後來弄得差不多了，就想打打飛機上的 Insaniquarium XDDDD
非常意外有這個東西。去時就有看到，不過懶得打。
回來時試了一下，就手癢打了一陣子，發現了：
1. 魚居然都有數量限制！
2. 儘管有限制，人魚唱歌時還是會 lag XDDDD
3. 一開始沒想到前頭有坐人，一直戳螢幕，真抱歉 XD
4. 換前頭沒人的座位，戳螢幕戳到手很酸... 左右手交替使用 @@
5. 為什麼沒有任何 PopCap 的字樣？
6. 我忘記那怪魚是吃 star, 不是吃 star potion XDD
7. 蝸牛和水母最重要，因為手會酸...
8. 打到後來好像當掉了？直接跳回第一關？算了就不打了
後來想想，也許是因為去時實在太冷了，而且一直在昏睡，
因此感覺就很漫長吧？後來愉快地準備 slide, 而且沒那麼冷，
加上又在打水族箱 XD 就覺得很短暫了。也只有降落時，
把東西都收好閉目養神時才昏睡過去。
這跟平常一上車和飛機就狂昏睡確實差不少...
suddenly you just fall asleep and
have no idea why it happens.
*
總而言之，in short, 就算說不上百感交集，
或許也有十感交集吧。好壞參半，我猜。
剛回來時心情也不錯，直到知道相機真的不見為止。
而到底是怎麼不見的，卻一點也不知道..。
我被講到真的以為是忘記帶，然後就忘記這件事了。
但既然家裡找不到，那應該真的是弄丟，或是被偷了吧？
只是覺得很無言的是，居然連一眼都沒瞧見就這樣不見了...
*
有時候不禁就想起很多事，陷入自己的沉思，
有些是記憶中的事，有些是自己無中生有的事，
有些則是兩者的混合產物。不，應該說大多數，
甚至全部都是如此。
加上第二天還第三天時就覺得感冒了，頭很沉重，
喉嚨痛，流鼻涕，沒體力... 這種時候總是會特別覺得無助。
幸好後幾天比較好了，頂多只是覺得很累或是不耐煩而已。
不知道是因為水土不服，還是差點被凍死的關係..?
冷斃了，啥鬼熱浪啊 :( 有些地方比台灣還冷很多，
我卻只有短袖和一件穿去的外套能穿 @@
是說當地人很多都只穿短袖短褲啦....... 太健壯了 XD
*
其中一個，比方說，在中正機場時，不斷想起來的卻是小時候
在打 game gear, 六顆 AA 電池，卻只能打約半小時？的時候。
現在比較想得起來的遊戲只有 sonic 和米老鼠的。
那感覺其實很奇妙。我現在倒是想不太起來，
不排除是因為太晚了很想睡...... 04:47
睡了，待續...
==
也許我需要好幾天調睡眠狀況 @@
那幾天的睡眠狀況真的是一整個慘啊
==
inbox"es" 還有一堆要看的 :/
2009-08-13
functional programming
晚上寫起投影片草稿，也算是畫點地圖吧。
沒想到這樣五個小時就去了 @@ 害我現在累死了 orz
主要是自己很多細節定義都不清楚，查資料和重新理解，
都費神費時又費力...
好在現在 wikipedia 很方便，不是他很正確，
（不過基本上我是覺得正確率相當高，當然不是在說 zh 版）
（會說 wikipedia 錯誤很多的人，發現都是在講 zh 版...）
而是他很多東西都寫得很清楚，方便你再去找其他資料。
也忽然想到，之前本來想把 rubinius 那篇的草稿，
整理一下當大綱貼出來。不過後來一直沒整理，
就一直沒有貼... 那大概變成萬年 draft 了 @@
另一個 blogger draft 是之前我想講程式是用屍體疊出來的，
這篇後來就忘記了，又覺得可以繼續寫，所以也是萬年 draft...
我看有機會的話，那兩篇重新整理起來可以再貼出來。
這樣就所有 post 都是公開的了。
*
其實我本來想把重點放在 algebraic datatypes 上，
但發現基本的東西列完篇幅就好長了...
不知道是不是應該調整一下，
把一些比較「實用」的東西，搬到前面一點...
anyway, 反正久了就知道怎麼拿捏了。
2009-03-10
ruby object model (0)
上次聊過的 rubinius,
http://blogger.godfat.org/2008/12/rubinius-slide.html
一直說要詳細描述一下裡面的 object model, 不過一直遲遲沒有動手。
那就趁這個機會寫一下好了，雖然我不知道現在這樣能不能寫得清楚流暢，
但總之有個第一版總比什麼都沒有好，這樣吧。
請看這張圖：
這是我用 Visual Paradigm 的 UML 程式大概畫的，
當然，不是照 UML 的規格，只是拿這來畫圖表似乎比較方便。
因為會需要不斷調整各個方塊和箭頭的位置，用投影片軟體會做到瘋掉。
就像投影片第 123~127 張，其實我們大致可以把 object 分成三群，
分別是 instance 層級、class 層級與 meta-class 層級。
投影片中的第一個圈是 class 層級，第二個圈也是 class 層級，
而第三個圈則是 meta-class 層級。這裡沒有畫出 instance,
因為那比較簡單，大家都知道。而第二和第三個圈，雖然都是 class,
不過由於第二個圈，也就是 Module, Class, 和 MetaClass 比較特別，
所以投影片上才特別畫出來。至於這裡則先不要看那兩個圈有什麼不一樣。
雖然不一樣，但套用 Ωmega 的說法：
[quote="Programming in Ωmega"]
在這裡，values 就是 instance, types 就是 class, 而 kinds 就是
meta-class, 至於 sorts? Ωmega 會無窮延伸下去，直到 *∞, 而 ruby
則會收斂至 meta-class. 所以 ruby 裡就沒有類似 sorts 的東西。
但事實上，當然沒辦法一對一對應這種概念。ruby 有一個設計原則，
就是方便性比合理性重要。所以他的 consistency 並不高，instance
是隸屬於 class 沒錯，而 meta-class 卻也仍然是隸屬於
class, 並不是 meta-class, 更不是 meta-meta-class;
同時，他們自己也是 instance.
所以用很白話的說法，ruby object model 遵守兩個原則：
1. 所有的值（value）都是 instance.
2. 所有的 instance 都來自某個 class.
如果你發現推導出來的結論，違反這兩個原則的話，
不管這個推導對不對，全部都不算數。因為，ruby 希望的是
符合人性，如果人性是矛盾的，則 ruby 的規則也是矛盾的。
雖然我們會說有 meta-class 的存在，是 class 的 class,
但 meta-class 事實上仍然是一個 class. meta-class 只是
一個解釋上的概念，而並不是真的有這樣的概念存在。
也因此，我們可以很簡單把所有的東西都視為同一件事，
很簡單地做到幾乎不受任何限制的 polymorphism,
不會像 Agda2 那樣碰到 Set1, Set2, Set∞ 之類的問題...
ruby 的 meta-meta-meta-class 並不是像那樣的東西。
而到底哪一種比較好呢？我認為無窮延伸下去是比較合理的。
但現實上無窮延伸下去到底有什麼用，可以帶來什麼好處，
可能沒多少個人有辦法回答吧...
所以我會說 ruby 的這種方式比較不合理，但比較有用。
可是究竟有用在哪？我們真的需要 meta-meta-meta-class 嗎？
我還沒想到有什麼非常實際的用法，通常 meta-class 就足矣。
*
回到本文的圖片。白框表示該 instance 的 class,
黑框表示該 instance 的 meta-class. 藍框則是 parent,
是 class 才會有的屬性。而 meta-class 實際上也是 class,
所以當然也會有 parent. 沒有 parent 的，只有 instance.
class hierarchy 最直接影響到的，當然就是 method dispatch.
所以投影片裡，下一個也就是講 method dispatch.
因為 ruby 並沒有 multiple inheritance, 所以不會有可怕的
ambiguous 問題。一個 class 的 method dispatch path,
最終一定可以拉成一條直線。
這條直線就是從 meta-class 開始走。
隨後則是沿著 parent 這條路走。
instance => meta-class => parent => ... => parent
這就是唯一的那條 dispatch 路線了。對於不管是哪個 instance
皆然。所以對於 class 當然也是這樣的。於是可以開始探討那個
最早的 meta-class 是什麼東西了？
lukhnos 說他覺得這件事說得最好的，是 David A. Black 的
Ruby for Rails 這本書。後來因為好奇翻了一下，不過沒找到
是在哪裡描述這段，然後就沒耐心了..........
他還說這聽起來與 Smalltalk 的 spec 上的描述差不多，
不過這個我一直沒有找時間去 review 一下，改天有機會吧。
meta-class 的存在，大抵上是為了兩件事：
1. singleton method
2. class method
在 prototype-based programming languages 裡面，
singleton method 是一件很自然的事。因為沒有 class,
所以我們當然得對所有的 instance 定義「獨特」的 method.
事實上，這也是為什麼我認為 ruby 是可以寫得很有 prototype 的味道。
由於 singleton method 的獨特性，我們當然會期望他是
the most special(important) method, 所以當然是他去
override 其他所有的 method. 因此，他必然得是第一個被 lookup.
接下來，我們當然得去該 instance 的 class 去搜尋，
然後則是 parent, parent, parent, etc. 那麼與其把路徑做成：
instance => meta-class
class => parent => ... => parent
變成要走兩條路，不然就把他們接起來？變成：
instance => meta-class => parent => ... => parent
那麼我們就得到一個 instance 的 meta-class 的 parent,
其實就是該 instance 的 class! 如圖 MetaClass d 的
parent 其實就是 D. 這邊是我最早提到三個圈裡面的第一個圈，
instance 層級的部份。對於 instance, 他的 meta-class 的
parent, 就是其 class.
至於第二個原因，class method, 則是 class 層級的事。
既然什麼東西都是 instance, class method 又為什麼不是
instance method? 事實上，class method 確實就是
instance method, 只是觀察的角度不同而已。
class Human; def self.create; end; end
class Mutant < Human; end
Human 的 create, 就是 Human 的 class
(其實是 meta-class) 的 instance method.
但是其實 Human 的 class 並不是真的 Human 的 class.
Human.class 的結果會是 Class, 因為我們認定所有的 class
的 class 都是 Class, 這就是某種矛盾。因為事實上，真正的
class 是 MetaHuman 才對。
這樣做的理由很簡單。因為如果 Class 是 Human 真正的 class,
那你定義 Human.create 時，事實上就會導致 Fixnum.create 也有效。
因為 Fixnum 與 Human 同樣都是 Class 的 instance!!
所以為了人性（矛盾）的 class method, 我們不能把 Class 當真正的
class. 於是 MetaHuman 被插進來了，create 這個 method, 會被放入
MetaHuman, 然後 Human.create 就得以成立；Fixnum.create 不成立。
因為 Fixnum 跟 MetaHuman 並沒有任何關係。
也就是說，class method 是定義在其最獨特的 meta-class 中，
跟 singleton method 一樣！
於是 class method lookup, 也可以依照同樣的路線：
class => meta-class => parent => ... => parent
這些 parent, 很顯然其中一個就會是 Class.
而為了使得 Mutant.create 也成立，也就是說，super-class 的
class method, 也可以是 derived-class 的 class method.
那麼，MetaMutant 的 parent 就會是 MetaHuman.
依照上述的路線，Mutant.create 會先搜尋 MetaMutant,
發現找不到，然後去其 parent 也就是 MetaHuman 尋找！
回到我們的圖，這裡 MetaHuman 就是 MetaClass C,
而 MetaMutant 就是 MetaClass D.
C 的 class method, D 也看得到。
往上繼續追，MetaClass C 的 parent 是 MetaClass Object,
因為 Class 也是 Object, 所以 Object 的 class method,
C, D 也都看得到。
注意到了嗎？這裡就可以看出投影片圈圈。class 有的 hierarchy,
meta-class 也有。下面是怎麼繼承的，上面也會怎麼繼承。
這邊就是 class 層級的 object model.
*
剩下 meta-class 層級的部份，欲知詳情，下回分曉。
因為我寫不下去了，腦袋一片混亂...
http://blogger.godfat.org/2008/12/rubinius-slide.html
一直說要詳細描述一下裡面的 object model, 不過一直遲遲沒有動手。
那就趁這個機會寫一下好了，雖然我不知道現在這樣能不能寫得清楚流暢，
但總之有個第一版總比什麼都沒有好，這樣吧。
請看這張圖：
這是我用 Visual Paradigm 的 UML 程式大概畫的，
當然，不是照 UML 的規格，只是拿這來畫圖表似乎比較方便。
因為會需要不斷調整各個方塊和箭頭的位置，用投影片軟體會做到瘋掉。
就像投影片第 123~127 張，其實我們大致可以把 object 分成三群，
分別是 instance 層級、class 層級與 meta-class 層級。
投影片中的第一個圈是 class 層級，第二個圈也是 class 層級，
而第三個圈則是 meta-class 層級。這裡沒有畫出 instance,
因為那比較簡單，大家都知道。而第二和第三個圈，雖然都是 class,
不過由於第二個圈，也就是 Module, Class, 和 MetaClass 比較特別，
所以投影片上才特別畫出來。至於這裡則先不要看那兩個圈有什麼不一樣。
雖然不一樣，但套用 Ωmega 的說法：
[quote="Programming in Ωmega"]
All values are classified by types that are classified by *0.[/quote]
All types are classified by kinds that are classified by *1.
All kinds are classified by sorts that are classified by *2,
etc.
在這裡，values 就是 instance, types 就是 class, 而 kinds 就是
meta-class, 至於 sorts? Ωmega 會無窮延伸下去，直到 *∞, 而 ruby
則會收斂至 meta-class. 所以 ruby 裡就沒有類似 sorts 的東西。
但事實上，當然沒辦法一對一對應這種概念。ruby 有一個設計原則，
就是方便性比合理性重要。所以他的 consistency 並不高，instance
是隸屬於 class 沒錯，而 meta-class 卻也仍然是隸屬於
class, 並不是 meta-class, 更不是 meta-meta-class;
同時，他們自己也是 instance.
所以用很白話的說法，ruby object model 遵守兩個原則：
1. 所有的值（value）都是 instance.
2. 所有的 instance 都來自某個 class.
如果你發現推導出來的結論，違反這兩個原則的話，
不管這個推導對不對，全部都不算數。因為，ruby 希望的是
符合人性，如果人性是矛盾的，則 ruby 的規則也是矛盾的。
雖然我們會說有 meta-class 的存在，是 class 的 class,
但 meta-class 事實上仍然是一個 class. meta-class 只是
一個解釋上的概念，而並不是真的有這樣的概念存在。
也因此，我們可以很簡單把所有的東西都視為同一件事，
很簡單地做到幾乎不受任何限制的 polymorphism,
不會像 Agda2 那樣碰到 Set1, Set2, Set∞ 之類的問題...
ruby 的 meta-meta-meta-class 並不是像那樣的東西。
而到底哪一種比較好呢？我認為無窮延伸下去是比較合理的。
但現實上無窮延伸下去到底有什麼用，可以帶來什麼好處，
可能沒多少個人有辦法回答吧...
所以我會說 ruby 的這種方式比較不合理，但比較有用。
可是究竟有用在哪？我們真的需要 meta-meta-meta-class 嗎？
我還沒想到有什麼非常實際的用法，通常 meta-class 就足矣。
*
回到本文的圖片。白框表示該 instance 的 class,
黑框表示該 instance 的 meta-class. 藍框則是 parent,
是 class 才會有的屬性。而 meta-class 實際上也是 class,
所以當然也會有 parent. 沒有 parent 的，只有 instance.
class hierarchy 最直接影響到的，當然就是 method dispatch.
所以投影片裡，下一個也就是講 method dispatch.
因為 ruby 並沒有 multiple inheritance, 所以不會有可怕的
ambiguous 問題。一個 class 的 method dispatch path,
最終一定可以拉成一條直線。
這條直線就是從 meta-class 開始走。
隨後則是沿著 parent 這條路走。
instance => meta-class => parent => ... => parent
這就是唯一的那條 dispatch 路線了。對於不管是哪個 instance
皆然。所以對於 class 當然也是這樣的。於是可以開始探討那個
最早的 meta-class 是什麼東西了？
lukhnos 說他覺得這件事說得最好的，是 David A. Black 的
Ruby for Rails 這本書。後來因為好奇翻了一下，不過沒找到
是在哪裡描述這段，然後就沒耐心了..........
他還說這聽起來與 Smalltalk 的 spec 上的描述差不多，
不過這個我一直沒有找時間去 review 一下，改天有機會吧。
meta-class 的存在，大抵上是為了兩件事：
1. singleton method
2. class method
在 prototype-based programming languages 裡面，
singleton method 是一件很自然的事。因為沒有 class,
所以我們當然得對所有的 instance 定義「獨特」的 method.
事實上，這也是為什麼我認為 ruby 是可以寫得很有 prototype 的味道。
由於 singleton method 的獨特性，我們當然會期望他是
the most special(important) method, 所以當然是他去
override 其他所有的 method. 因此，他必然得是第一個被 lookup.
接下來，我們當然得去該 instance 的 class 去搜尋，
然後則是 parent, parent, parent, etc. 那麼與其把路徑做成：
instance => meta-class
class => parent => ... => parent
變成要走兩條路，不然就把他們接起來？變成：
instance => meta-class => parent => ... => parent
那麼我們就得到一個 instance 的 meta-class 的 parent,
其實就是該 instance 的 class! 如圖 MetaClass d 的
parent 其實就是 D. 這邊是我最早提到三個圈裡面的第一個圈，
instance 層級的部份。對於 instance, 他的 meta-class 的
parent, 就是其 class.
至於第二個原因，class method, 則是 class 層級的事。
既然什麼東西都是 instance, class method 又為什麼不是
instance method? 事實上，class method 確實就是
instance method, 只是觀察的角度不同而已。
class Human; def self.create; end; end
class Mutant < Human; end
Human 的 create, 就是 Human 的 class
(其實是 meta-class) 的 instance method.
但是其實 Human 的 class 並不是真的 Human 的 class.
Human.class 的結果會是 Class, 因為我們認定所有的 class
的 class 都是 Class, 這就是某種矛盾。因為事實上，真正的
class 是 MetaHuman 才對。
這樣做的理由很簡單。因為如果 Class 是 Human 真正的 class,
那你定義 Human.create 時，事實上就會導致 Fixnum.create 也有效。
因為 Fixnum 與 Human 同樣都是 Class 的 instance!!
所以為了人性（矛盾）的 class method, 我們不能把 Class 當真正的
class. 於是 MetaHuman 被插進來了，create 這個 method, 會被放入
MetaHuman, 然後 Human.create 就得以成立；Fixnum.create 不成立。
因為 Fixnum 跟 MetaHuman 並沒有任何關係。
也就是說，class method 是定義在其最獨特的 meta-class 中，
跟 singleton method 一樣！
於是 class method lookup, 也可以依照同樣的路線：
class => meta-class => parent => ... => parent
這些 parent, 很顯然其中一個就會是 Class.
而為了使得 Mutant.create 也成立，也就是說，super-class 的
class method, 也可以是 derived-class 的 class method.
那麼，MetaMutant 的 parent 就會是 MetaHuman.
依照上述的路線，Mutant.create 會先搜尋 MetaMutant,
發現找不到，然後去其 parent 也就是 MetaHuman 尋找！
回到我們的圖，這裡 MetaHuman 就是 MetaClass C,
而 MetaMutant 就是 MetaClass D.
C 的 class method, D 也看得到。
往上繼續追，MetaClass C 的 parent 是 MetaClass Object,
因為 Class 也是 Object, 所以 Object 的 class method,
C, D 也都看得到。
注意到了嗎？這裡就可以看出投影片圈圈。class 有的 hierarchy,
meta-class 也有。下面是怎麼繼承的，上面也會怎麼繼承。
這邊就是 class 層級的 object model.
*
剩下 meta-class 層級的部份，欲知詳情，下回分曉。
因為我寫不下去了，腦袋一片混亂...
2008-12-24
Rubinius slide
以後所有的投影片我都會放在：
http://godfat.org/slides/
（之前的就... 哪天從硬碟裡挖出來，我覺得不會太傷眼的，就會放上去）
Rubinius 的在：
http://godfat.org/slides/2008-12-21-rubinius.pdf
想看 source 也行：
http://godfat.org/slides/src/
這次的 source 是：
http://godfat.org/slides/src/2008-12-21-rubinius.key.tgz
任何想法都可跟我反應，非常感謝！
p.s. 後面 object model 的部份沒弄好，metaclass 應該是往上，而不是往下。
由於 keynote 不是那麼容易讓我隨便編輯，當時也已經弄好了，就懶得修正了...
關於這點感到有點抱歉，如果當初用 flash 編輯的話，大概就可以快速反轉吧 :s
2008-12-04
ruby object model (2)
這幾天想這個 object model 感覺快要腦炸了。奇怪，應該沒那麼難啊，
為什麼一直搞得很困惑？？是我變笨了還是其實真的很複雜？
Rubinius 試半天，認為圖應該沒畫錯，事實上應該確實是 Rubinius 的
object model 沒錯。但事實上，在 MRI 和 JRuby 又不一樣...
可以看這兩個 rubinius tickets:
1. calling a 'class' method on an object's metaclass should
invoke the class method of the object's class
2. Kernel and IncludedModule
第一個的重點是：
http://gist.github.com/31903
b = B.new
# false in Rubinius, true in MRI, JRuby
p b.metaclass.superclass.object_id == B.metaclass.object_id
b.meta_def(:cheese) {'cheshire'}
# false in all implementation
p b.metaclass.superclass.object_id == B.metaclass.object_id
1. MetaClass d 的 superclass 不是 D, 而是 MetaClass D !!
2. MRI/JRuby 的 metaclass 會改變！
第一點會造成推斷出來的 method lookup 規則有例外！
第二點則是... Charles L 認為這是合理的。
不過我還不太懂他的意思，我只知道使用前和使用後有所差異是詭異的。
就算這應該是 lazily created, 這是當然的，畢竟我們不可成真的產生
窮盡記憶體的 metaclasses. 但是也不能因此先丟個毫無關係的 B 進去吧？
copy on write 仍然必須維持 proxy 的特性啊。我不覺得應該因此改變結構。
第二個重點則是：
http://gist.github.com/30606 的第三則
MRI 和 JRuby 大概是不管怎麼樣，反正插進去就是了。所以他不會影響到已存的
class 們。但是 Rubinius 卻會翻之前的 module 出來重新一個個插進去：
kernel/delta/module.rb: 63~74
if ancestors.include? mod
ancestor = superclass_chain.find do |m|
m.module == mod if m.kind_of?(IncludedModule)
end
ancestor.module.included_modules.each do |included_mod|
included_mod.send :append_features, ancestor
included_mod.send :included, ancestor
end
else
mod.send :append_features, self
mod.send :included, self
end
這個.... 我不知道誰的作法比較好，總之不一樣就是了。
其他一點相關的知識：
=== 是判斷 kind_of? 和 ==（或 eql? equal? 搞不清楚）
但奇怪的是 Fixnum === Fixnum 又是 false.
而 Fixnum === 1 和 1 === 1 又是 true.
思考方法是，你覺得 case 裡面應該要怎麼樣判斷正確？
所以至少就會是 equality, kind_of, 還有 includsion.
例如 (1..10) === 5 也要是 true.
個人建議是不要用這個 method, 那是留給 case 用的。
然後 kind_of? 的判斷並不是看 ancestors,
而是 ancestors 和 metaclass 的 ancestors 都算。
因此 Fixnum.kind_of? Object.metaclass 也會是 true.
這些都算是為了方便所以做的，所以規則有點恐怖...
==
唉，不過我真有點不想再想這個了，覺得快腦炸了。
2008-12-03
ruby object model
對於 ruby object model 一直是懵懵懂懂的，這幾天決意畫出圖表，
想說畫出來後應該就清楚了吧！結果紙筆畫不出來，因為太複雜了。
後來去找畫圖表的程式，先是試試 free mind, 不過發覺這不是拿來畫圖的|||b
後來找來找去好像還是找畫 class diagram 的程式比較快，就試了 Visual Paradigm.
雖然實在又肥又大，居然要一百多 MB... 然後我只用到 class diagram,
其他有的沒的完全用不到。anyway, 發覺還滿好用的，gui 上設計得不錯。
比較可惜的是，箭頭種類太少，aggregation 和 composition 的圖形不太喜歡。
我又不是真的要畫 class diagram, 只是希望有拉箭頭方便的程式...
花了好幾個小時畫完第一版，很滿意地去睡了。隔日越想越不對，好像哪裡怪怪的。
仔細看了和實驗之後發覺，確實寫錯了，把兩個不同的東西混成一個。
這部份重新畫過之後發覺....
第一版就讓我覺得畫出來反而更混淆！因為密密麻麻的，見樹不見林...
但第二版更是複雜很多，因此我把文字註解都刪除了。搭配實驗與另一篇文章的解釋，
總算大概釐清了一些頭緒。同時也覺得 ruby object model 其實很矛盾...
這也是在說明，人類的直覺，往往是很矛盾的 :(
anyway, 後來在實驗 include module 的部份，忽然更讓我困惑了。
因為這邊 Rubinius 和 MRI/JRuby 的行為都不同，
讓我搞不清楚到底怎麼樣是對的了。好像必須循其本，想想 mixin 是什麼。
老實講，不管哪個實作，跟我的直覺都不太一樣。
關鍵在 kernel/delta/module.rb 裡的 include 和 append_features.
現在必須思考的是，為什麼要這樣做？
亂註解掉修改 ancestors 的部份就能跟 MRI/JRuby 一致了。
但，why? why?
==
我覺得好蠢，光在思考卻不看程式碼，看了程式碼才發現很多推測其實是錯的。
值得高興的是大部份是對的就是了...
壞毛病。
2007-06-24
The Lost Piece 迷失的一角
嗯…該從何處說起呢？想多說些，卻又懶得娓娓道來。
總而言之啊，那些信件真的讓我印象非常深刻。
而這也是個非常容易讓我這種，手殘眼殘的人發揮的方式。
再加上正好有人報告過，集各種推力於一身，豈有不用之理？
強烈建議先讀過原著：
博客來
阿媽爽
使用程式是：
1. Paint.NET（非常難用！只是別無選擇，我懶得再找了）
2. OpenOffice Impress（串成 odp 檔再輸出 pdf）
The Lost Piece 迷失的一角
高橋流投影片做到一半沒做了啊… orz
edited:
在第二十九頁追加了本網站的連結。
順便提提後面本來想加的，是 polygon 和遞迴唷。
Subscribe to:
Posts (Atom)
