※ 引述《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