採用可變ARGS語法速記時，列表和方法簽名重寫可

對於有列表的簡單語法速記語言，前採用可變ARGS語法速記時，列表和方法簽名重寫可

x = [1,2,3];

而且超載職能不同簽名的能力...

對於函數的變量參數語法是否有任何用法，這些函數不會像通過列表清楚地做到的那樣？例如，對於可變參數一個常見的用途是一個printf類型的語句：

printf("This is %s while this is a number %d\n", "a string", 10);

然而，你可以很容易和清楚地做了以上：

printf("This is %s while this is a number %d\n", ["a string", 10]);

的唯一的事情我已經能夠提出到目前爲止將實施控制流程結構，如if/elseif/else，你想要能夠通過可變數量的elseif/else塊。但是，這可以通過將elseif分成else並將if作爲單個命令來避免。

那麼，有沒有類型的東西不能做（乾淨/清晰）沒有專門有一個可變參數語法？

來源

2011-11-14 RHSeeger

注意的參數列表中的printf由不同類型的元素。所以這種解決方案在靜態類型語言中是不可能的，沒有對異構列表的類型系統支持。 – nponeccop

@nponeccop：嚴格來說，不是，如果所有對象都從基類繼承，則它們也可以被轉換。 – RHSeeger

不在此上下文中。要求函數的所有參數實現相同的接口並不是一個好主意。與函數接受列表相反，函數具有可變參數的想法是，它們可以像函數的作者所期望的那樣不同。 – nponeccop

即使速記列表可以達到相同的目的，也應該包含變量參數，因爲它們增加了直觀性並減少了錯誤。

[這是假設您同意的語言特性可接受的「使用」是直觀和減少錯誤。]

我的依據是在專有同時具有這些特徵的純粹根據經驗遊戲腳本語言和觀察到的學習曲線以及用戶所犯的常見錯誤。 [用戶從全新的學校到行業資深人士，在幾個多年的項目中，在過去的十年半時間裏，在不同的遊戲公司中 - 最大的是160名團隊成員（20個核心腳本用戶+ 50個左右腳本實時）命令「在線」用戶）。有些是純粹的腳本編寫人員，只知道這種腳本語言或一些其他人，有些人也是專業的C++程序員 - 兩個組在這個問題上似乎都有相同的結果。]

[如果它是相關的 - 我基於此也有可變參數類型，並且所有類型都有一個共同的基類。]

多年來，我創建了許多雙方法，雖然一個使用可變長度參數，另一個使用了列表。在內部，具有不同接口的方法都歸結爲相同的代碼 - 它們僅僅是風格上的語法差異。

在「狂野」中，我發現使用帶兩個附加字符的速記列表的機制意味着只有兩個字符可以被遺忘。我基於這樣的次數，我被稱爲「幫助」那些在基於列表的版本的方法中遇到麻煩的用戶，而不是可變參數方法。

至於直觀我已經做了方法的一些分析/計數和使用可變長度方法實例的數量大大壓倒了列表的方法。另外當被問及人們在美學上更喜歡變量arg版本時。

但是我仍然相信在使用基於列表的方法時尤其如此，特別是在進行更復雜的調用和元編程時非常實用，因爲將一組參數作爲單個單元和通用列表函數進行處理十分方便 - 交集，工會，過濾等也可以用於參數。

雖然多年來我發現這個規則的一個有效例外，但我只是增加了必要的功能以減少給定程序員在任何時候需要保持頭腦的量如果某個功能更易於使用或導致更少的錯誤，則有時會提供保證。 [我寫了一個早期的腳本語言是非常精簡 - 在我看來優雅 - 儘管我學到了艱辛的道路，人們喜歡它越來越具有較少的問題，這一次，我發展它有一個一點更多的「冗餘」以直觀性和錯誤減少的名義。]

很顯然，不同的語言與這些功能和不同的用戶和域周圍的不同元素可能會有不同的結果 - 儘管對於它的價值我相當有信心根據我有多長時間提出了我的觀察。

[另外]

變量指定參數和速記列表之間的另一個電位混凝土差取決於語言是否可以指定之間如何參數傳遞到方法/函數接口的可變ARG方面的差以及用作速記列表中的元素的參數/語句。

如果變量arg參數可以指定超出可以爲速記列表指定的內容（反之亦然） - 即參數通過引用而不是按值傳遞，則參數將使用某種惰性評估或者在通話中進行評估等等 - 然後可以用一種或另一種語法來完成更多。

這確實是語言相關的，如果一個變量參數「組」或簡寫列表元素使用的可能是參數以相同的方式「通過」就沒有區別。

來源

2011-12-22 09:45:36

我承認，我正在尋找更多的是通過一種語法而非另一種語法實現的事情。話雖如此，我覺得你的答案非常有說服力。 – RHSeeger

謝謝。我知道你希望得到更多 - 我自己對你的問題非常感興趣。除了直覺和錯誤之外，我從未發現真正的*實際*差異。我做了一些使用早期語言的東西，它使用了類型化變量args（直到與var arg不同的類型被擊中時才被貪婪接受）以及惰性評估來創建自定義控制結構。我發現大多數人在內置控制語句方面存在「得到它」的問題 - 並且使用簡寫列表可能更簡單，而不是使用類型作爲「分隔符」的編譯器。 –

提到懶惰的評價讓我思考了變量論證和速記列表之間參數的傳遞是如何不同的，所以我在「[Also]」之後擴展了我的答案。 –

對於if/elseif/else問題，在LISP like語言中存在50年左右的解決方案 - 查找COND。

(COND 
    (condition1 value1) 
    (condition2 value2) 
    (condition3 value3) 
    (T default))

來源

2011-11-16 14:22:05 Ingo

雖然我一直在COND語法的粉絲爲代表長IF/ELSEIF鏈，它並沒有真正解決問題的可變參數更可讀的方式。事實上，它是最可讀的形式，它比if/elseif命令結構所需的可變參數要多。 – RHSeeger

採用可變ARGS語法速記時，列表和方法簽名重寫可

回答

相關問題