Re: [問題] 為什麼local variable的scope不能延及ꐠ…
※ 引述《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
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 9 篇)：
PLT 近期熱門文章
PTT數位生活區 即時熱門文章
