※ 引述《godfat (godfat 真常)》之銘言： : 這篇 copy & paste 過來的，所以沒什麼 p 幣... : ※ 引述《mystea (mystea)》之銘言： : : 請問您所提的減少dependency是不是指希望有generality以增加重複使用的機會? : : 但其實有時候call by reference並不一定減少了generality. 比方說我想寫一個 : : fit line的程式, 輸入值是兩個平面上的點, 輸出值是直線方程式的a和b; 因為輸出值 : : 超過一個, 所以不用pass by reference不行, 但是既然目標很明確, 兩個平面上的點 : : 的資料型態並不是母程式獨有的, 那重複利用性應該也不差才是阿... : 不完全是，另一方面是減少 side-effect, side-effect 通常會使得複雜度大增。 : 至於你所說的輸出超過一個，跟要不要用 side-effect 沒有直接關係。例如你可以回傳 : tuple, 甚至是另一個 data type. 不過你說的資料型態並不是母程式獨有的， : 這句話我不太懂是什麼意思？ 我的意思只是說, 座標是一個大家都使用的資料型態, 而不是為母程式裡量身訂做的一種 資料型態. 但我不太懂你所說的side-effect是甚麼意思? : 另一方面，要達到模組化其實跟 side-effect 並沒有直接的關係。甚至是有 : side-effect 模組化能做得更好。雖然也很有可能做得更差。簡單地說其實 : 都是 trade-off... 也沒什麼說怎麼樣一定比較好，端看怎麼用吧。 : : 但是如果我的子程序是在動態宣告母程序裡的local variable的話, 好像就不會違反 : : generality了. 比方說我寫一個fit line的程式, 輸入是兩個點的座標, 輸出則是兩 : : 個叫做fitline_a, fitline_b的 母程序裡的 local variable, 像這樣的話重復利用性 : : 好像還要更好呢! (因為使用之前不需要特別為他宣告兩個變數) : 我只能說... 你這樣寫起大程式，只會一片混亂。要寫 quick and dirty 的程式， : 當然是越少限制越好了，反正一切都交給 programmer 就對了。但是當你程式一大， : side-effect 一多，情況就會不可收拾了。假設現在是 100 人在寫程式， : 你怎麼會知道你寫的東西不會跟他打架？假設都不會好了，人類的腦袋又怎麼有辦法 : 記起來所有可能的變化與改變？（這時候是不是要接，不，如果是月就有可能？XD） : 如果你寫的東西永遠都不會干擾到別人，也就是沒有 side-effect, 或是只有 : 受限制的 side-effect, 那麼就不需要擔心這種爆炸性的組合狀況了。 恩, 我昨天po文的時候有想. 我們可以定義一個特別的namespace, 專門留給這些 子函式製造的變數. 比方說子函式fitline產生的變數a可以叫做 fun::fitline::a (但是scope在main!), fun就是留給子函式們的namespace. 因為只能有一個叫fitline的function, 所以這樣一定不會跟別人的程式打架. 像這樣吃進兩個點, 製造出兩個coefficient的函式, 算是有side-effect嗎? google了一下, 模組化的定義好像就是"不會影響到程式別的部份," 那是不是跟 side-effect的定義相同呢? 如果這樣為什麼有可能side-effect多但是模組化好? : 不過說是這樣說，如果你只是要動態修改 local variables, : ruby 可是真的可以這樣寫的 :p : godfat ~> irb : irb(main):001:0> def fun top : irb(main):002:1> eval 'a=10', top : irb(main):003:1> end : => nil : irb(main):004:0> fun binding : => 10 : irb(main):005:0> a : => 10 : 詳細我就不多說明了，這裡就是利用 fun 這個 function 替 top level scope : 定義 a 這個 local variable. : 也許 ruby 很適合你，歡迎到 ptt Ruby 板參觀 XD : 現在填寫板友名單有優待（誤） : > 我很願意聽godfat大講講local variable有甚麼好處. 我其實只上過最基礎 : > 的程設, 所以在理論方面很薄弱的. 一些基礎的問題很高興有版友願意指教. : 這個我也只能先聲明，我甚至沒受過正規的 computer science 教育... XD : 大部份的東西都是自己的一點經驗談，如果哪裡講得怪怪的，也請多多包涵， : 互相討論切磋，sincerely. 哇! 那godfat大真是太厲害了. 希望有一天我也可以跟他一樣(遠目). : local variable 的好處很多。減少 side-effect, 利用 automatic variable : 達成 C++ 上 RAII（Resource Acquisition Is Initialization）的手法、... : 嗯，其實我現在仔細想想最後都可以歸納成減少 side-effect XD : 當然這樣講是籠統了些... 可以小小歸結這次的結論嗎: local variable的scope被設定成僅限於自己, 連自己的 子函式都不能接觸到, 並不只是為了名稱可以重複使用. 最主要的原因, 還是因為"鼓勵"使用者寫出"模組化"的程式, 亦即, 程式各部份可以 視為獨立個體. 因為程式是以函式為最小的compile單位, 所以模組化的意義也可說就是, 函式與函式之間沒有實作上的依賴性. 一個能夠保證函式之間沒有實作依賴性的方法, 就是只使用local variable. 這麼說來, pass by reference也應該是不被鼓勵的囉?! 最好是能夠用tuple datatype 來取代. : 不過我想影響最大的可能還是遞迴吧，遞迴還是需要不同的 address space, : 不然有很多事情都會很難做到。 : > 遞迴的時候內定的namespace名稱可以加入son被呼叫的次數, 比方說堆疊最底層的son:i : > 叫son0:i, 接下來呼叫的叫做son1:i, son2:i, 等等. : 這個....... 先別說這對 compiler/interpreter 負擔有多大好了， : 要是遞迴有這種機制，我也可還真不知道怎麼用他比較好哩？更何況，這 : name binding 要怎麼做？compile time 當然不會知道 call stack 的 : 狀況，所以完全變成 dynamic binding 嗎？然後去 random access call stack? : 會不會有點太瘋狂了些... @@ 這樣用 call stack 不就失去很多意義了？ : > 當然上一篇的回應中我已經了解到一部分程式語言不支援修改外界local variable的 : > 原因. 所以像這樣回文只是希望能夠拋磚引玉. (比方說跟大家討論這種功能的可行性, : > 優缺點以及學習更多其他的原因等等:P) : 有些東西我想你需要考慮一下實用性和實作可能性，如果非常難做，獲得的好處又不多， : 甚至把一些原本的好處都打爛了，這樣的功能似乎就沒什麼意義。 : 最後，感謝你增加本板的文章 XD 看看日期，一個多月沒有新文章，好冷啊... 更謝謝眾版友願意解答疑惑, 陪我閒扯. XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 76.170.235.113