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?

==
我覺得好蠢，光在思考卻不看程式碼，看了程式碼才發現很多推測其實是錯的。
值得高興的是大部份是對的就是了...

壞毛病。