ts用得很爽，實現(xiàn)了我心目中關(guān)于類型的想法。類型!=面向?qū)ο蟆ｎ愋蜕踔敛皇钦鎸嵈嬖诘?#xff0c;運行期會移除，只是輔助代碼編寫。類型是別名，本質(zhì)上只要滿足鴨辨就是同一類型。聯(lián)合類型的區(qū)分太智能了，再以聯(lián)合字符串為本質(zhì)。字符串的等比較太常用了，在各lisp都成了match語法，進一步走向prolog，像sql分析數(shù)據(jù)庫。

類型有什么用？腳本語言本來有各種基礎(chǔ)類型，再標(biāo)注上各種類型，脫褲子放屁？而且很多復(fù)雜的類型手寫很困難，在ts里遇到了，java等傳統(tǒng)面向?qū)ο笳Z言不會遇到，但等效的在不斷創(chuàng)建新類型，代碼與概念暴增。標(biāo)注類型能幫我們靜態(tài)分析，在編譯期——類型語言是區(qū)分編譯期的。可是單獨編譯效率仍然太低下了，IDE能實時分析實時提示，與其說面向編譯，不如說面向IDE，有IDE這么智能的工具應(yīng)用起來，誰愿意回到刀耕火種的時代。

所以標(biāo)注準(zhǔn)確說不應(yīng)該叫類型標(biāo)注，而是面向IDE標(biāo)注，使用這樣的標(biāo)注方式，IDE能幫你檢查。代碼是實現(xiàn)需求，標(biāo)注是獲得檢查，腳本上的腳本，替代的是單元測試。以字符串聯(lián)合為基礎(chǔ)的ts，其實本身就更完善地覆蓋了很多單元測試的情況，少寫了很多代碼。為什么說是面向IDE而不是說強類型？很多時候手寫類型太多，類型間有因果關(guān)系，就希望用宏來生成類型，這時IDE實時執(zhí)行了宏腳本生成了目標(biāo)類型，也不用一次重構(gòu)處處修改，代碼更內(nèi)聚了。脫離了IDE談類型是無稽之談，編程語言更確切是某種IDE的特定交互方式，IDE就是最智能的人機交互。

驗錯，提示，重構(gòu)，是類型的用處。IDE可以對代碼序列化反序列化，用json-AST傳輸轉(zhuǎn)換成另一種語言。IDE應(yīng)該是方便復(fù)制拷貝的文本，容錯，下拉提示，錯誤提示，靈活的輸入——有了這些能力，可以用腳本靈活定制IDE。

————————————

量變引發(fā)質(zhì)變，雖然我自制的S-Lisp不帶類型標(biāo)注，但其實很多函數(shù)有明確的類型，但如果能明確地寫出來，至少可以減少長篇大論的說明吧。但一直也沒找到好的方法。

類型是確實存在的，作為S-Lisp的基礎(chǔ)類型，列表空布爾字符串?dāng)?shù)字(int)函數(shù)。意味著某些數(shù)據(jù)，在某些函數(shù)的操作下是絕對安全的，但如果是另一種數(shù)據(jù)，就是低級的錯誤。比如extend函數(shù)的第二個參數(shù)只能是列表或空，而不能是布爾/字符串或函數(shù)。

因為很多條件分支的嵌套，腳本語言很難檢查低級錯誤，但腳本確實很強大，基本上就是按照人的自然思路來。更別說parse函數(shù)等返回的類型的不確定性。腳本語言基本上是一個人是一條龍，三個和尚沒水喝。這時候似乎Java是更正式的，Java有強大的重構(gòu)能力，字段與類型的檢查，同時還有匿名類，基本上比其它面向?qū)ο笳Z言貼近函數(shù)式編程。

我曾簡單地設(shè)想對基礎(chǔ)的內(nèi)置函數(shù)標(biāo)注類型，在具體計算之外單獨做一次基于流程的lambda類型演算，保證系統(tǒng)至少不存在低級類型錯誤。其實如果從重構(gòu)角度，有了類型演算的檢查，重構(gòu)也會有保證了。我希望有一種簡化版的Java，保留其強大的類型與字段驗證、重構(gòu)能力和匿名類，必要時候可以舍棄類型的概念。

簡化的Java，應(yīng)該舍棄中綴表達式，幸虧Java還沒有自定義中綴表達式，不然優(yōu)先級也是一筆糊涂賬。中綴表達式只能接受兩個參數(shù)，老老實實用括號不會錯，如果用的是S表達式就更好了。Java沒有重載操作符，這也很好。Java還應(yīng)該加上空聯(lián)合，像kotlin一樣盡早區(qū)分。if語句與while語句應(yīng)該是函數(shù)式的，返回值，盡量無副作用，減少概念...。

總是難免要重構(gòu)的，尤其是分散的引用，乃至作為庫被別人引用。JS系字典作參數(shù)，增量的改造可以不處理，破壞性的改造，穩(wěn)妥的辦法就是新建帶版本號的函數(shù)，舊引用仍然能正常工作，但很丑，同時如果舊函數(shù)內(nèi)部本來存在邏輯問題，就沒辦法了。功耗可能要大一些。腳本的系統(tǒng)仍然得靠人的統(tǒng)籌管理（不過事實上現(xiàn)在的什么系統(tǒng)不是三五年就過時了？）

既然重大的重構(gòu)能力與類型演算殊途同歸，其實也只是回過頭考慮給腳本加上一些限制，使盡量保留腳本的靈活，同時獲得類型驗證。比如可能parse函數(shù)就沒有了。如果完全不寫類型標(biāo)識，可能問題比較多的是if語句。

我曾經(jīng)想聯(lián)合類型是像TypeScript一樣，與空聯(lián)合也只是普通的一種了。事實上每個列表（元組）類型都不同，函數(shù)更不同，便生出析分類型處理的問題，似乎超出了腳本的能力。然而事實上聯(lián)合的類型多了人也不好分辨，JS等只動態(tài)地檢查它是空/列表/布爾/函數(shù)/字符串，而Java里更只有與空聯(lián)合，那就只允許與空聯(lián)合吧。

因為不強制類型轉(zhuǎn)換，可能有個特殊的函數(shù)（或標(biāo)識），比如if-exist-run，將空聯(lián)合分成兩種情況分支去處理。然而和其它if語句一樣兩種情況只能返回一種類型，或者與空聯(lián)合，得檢查兩個分支返回的同一種類型（或內(nèi)中一種為空）。

如果完全不標(biāo)注類型，還有一點好處，所有函數(shù)都像C++中的泛型函數(shù)一樣，只要在具體運行場合不出錯就OK。在if系語句中如何確定自定義函數(shù)的類型？

而且類型隱含了兼容性，比如一個接受任意類型的函數(shù)，可以替代任何作參數(shù)的特定函數(shù)（還有返回值的約束）。kvs屬于List，兼容于List的所有操作。

在這其中其實我想到一種類型的表示方法，很S-Lisp，比如

Int/Int?/String/String?/Bool/Bool? [String Bool ...Int]/[?String Bool ...Int] {[String Bool]Int}/{?[String Bool] Int}

如果有泛型函數(shù)。如果返回值依賴回調(diào)函數(shù)？

事實上Java是有中間類型的，自定義類型，自定義類型雖然是一種類型的組合，但它是重構(gòu)的依據(jù)，與哪種類型保持一致。一般一個公開的Java類就是一個文件，如果能省下類型標(biāo)識就更好了。這時函數(shù)類型不能傳遞，if系語句的分支要么返回空，要么返回相同類型構(gòu)造而成。

Class是返回一組函數(shù)，以自己為類型。Function是返回已經(jīng)定義的Class類型。

類擁有一組函數(shù)。函數(shù)不能與實例脫離（就退化成傳統(tǒng)面向?qū)ο?#xff09;。匿名類與類的構(gòu)造應(yīng)該統(tǒng)一，像JS的字典一樣。哪些必須重寫，哪些可選重寫，哪些字典不存在不能重寫。函數(shù)的參數(shù)太長，也應(yīng)該用字段標(biāo)識。我們不需要知道類型，但又想獲得類型驗證的好處。

暫如此...

---

如果聯(lián)合類型，如用()表示，可能還有遞歸引用類型

[...xs] `0~N個相同類型` [x ...xs] `1~N個相同類型` ([...xs] Int String Bool Function) `即Any類型` `x是泛型函數(shù)的泛型可能依賴于入?yún)⒌念愋?#96;loop {[{[...xs][Bool ...xs]}...xs][...xs] }

量變引發(fā)質(zhì)變，而不是質(zhì)變造成量變，也許是不可逆的。

就像之前這loop函數(shù)，if語句的歸納聯(lián)合類型都不起作用了，真正的返回值根據(jù)具體情況來實現(xiàn)。因為loop本身也是靠遞歸來實現(xiàn)的，是因為它不是最終函數(shù)？

---

突然想到在具體的使用場合，業(yè)務(wù)邏輯的復(fù)雜化，Lambda通常會退化成Object，所以其實Java的Lambda本質(zhì)是匿名類，是一個正確的思路。必要的時候簡寫，為了語法的一致不簡寫也可以，反正能解決問題；簡寫成Lambda，反正有強類型驗證，重構(gòu)也容易。用類型基本上與DSL無緣了（不考慮kotlin之前，它的DSL中函數(shù)沒有強制約束實現(xiàn)。其實DSL有XML，它有類型檢查，只是稍改下語法就好）。其實我之前寫JS大多也成這種面向?qū)ο罅恕?/p>

編程中常用到Array與Map，其實就是js中的Array與Object。如果要強類型化，每一種又分為兩種，同類型的Array，不同類型的Array（元組）；同類型的Map，不同類型的Map（Object)。當(dāng)業(yè)務(wù)復(fù)雜后，Object很實用，但元組在局部場合也很實用。通常Object帶類型名（class），由前面的總結(jié)不再傳遞函數(shù)。loop語句也不考慮（Java里有while語句，可能需要進一步封裝使函數(shù)化，比如兩個回調(diào)函數(shù)，一個主判斷，一個主計算），reduce這種Java里也有實現(xiàn)。

將類的實例化與匿名化一體，像js中Object一樣鍵值映射，不區(qū)分值與函數(shù)，且最好是常不變的。如上，類是返回自身的函數(shù)，函數(shù)是返回已有類（現(xiàn)在可能是元組）。函數(shù)的參數(shù)是數(shù)組的，如何傳Lambda?函數(shù)也不能像類一樣重寫，那么函數(shù)傳lambda就是接受一個類（重寫）。而類實例化是重寫，還是接受一個參數(shù)（總要重寫，重寫什么？協(xié)議？）類的實例化有構(gòu)造函數(shù)嗎？如果是重寫，就可能沒有。如果是接受參數(shù)，就可能有。接受參數(shù)實例化，與函數(shù)返回，其實是一樣的。重寫其實是污染原作用域，而且沒有構(gòu)造過程，其實可能需要統(tǒng)一的構(gòu)造過程。但參數(shù)的話（實現(xiàn)契約）就可能需要默認(rèn)值，不過Java的協(xié)議目前也有默認(rèn)函數(shù)（只是不能保存狀態(tài)），而且個人不是很喜歡多協(xié)議實現(xiàn)。類也許不應(yīng)該繼續(xù)繼承，只能是協(xié)議繼承，而協(xié)議只能單繼承，不能保存狀態(tài)。協(xié)議實現(xiàn)為匿名類，作參數(shù)傳遞。如果選擇某個協(xié)議實現(xiàn)，倒是可能有默認(rèn)值。協(xié)議也沒有構(gòu)造函數(shù)。但協(xié)議的默認(rèn)值，似乎接受的類無關(guān)，不像js檢查某未實現(xiàn)。協(xié)議與執(zhí)行的目標(biāo)類有關(guān)，作為一種外部重寫，默認(rèn)值的處理辦法卻是妥協(xié)的。是否有必須實現(xiàn)與選擇實現(xiàn)？則可以檢查選擇實現(xiàn)是否已經(jīng)實現(xiàn)，倒是從內(nèi)部聲明默認(rèn)值。當(dāng)然協(xié)議實現(xiàn)匿名類，必須將未實現(xiàn)的動作都實現(xiàn)，默認(rèn)實現(xiàn)的當(dāng)然可以不實現(xiàn)了，最好可能調(diào)用super方法？但如果協(xié)議允許選擇實現(xiàn)，而有語法檢查到未實現(xiàn)，也許協(xié)議也不繼承。但如果有內(nèi)置默認(rèn)值，也會面對另一組默認(rèn)值組合的情況。有一個空的根協(xié)議，有一組默認(rèn)值協(xié)議（甚至可以自定義）。然后具體場合選擇實現(xiàn)哪一個協(xié)議。

集合與字典，需要泛型。如上，只是Java的一個子集。匿名協(xié)議實現(xiàn)，構(gòu)造函數(shù)入?yún)ⅰ５M返回呢？可能要常不變。

總結(jié)

以上是生活随笔為你收集整理的返回值类型有哪些_关于类型的思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。