คำถามติดแท็ก language-design

คำถามที่เกี่ยวข้องกับการออกแบบและโครงสร้างของภาษาโปรแกรม

4
จำเป็นต้องมีการรวบรวมขยะหรือไม่สำหรับการดำเนินการปิดอย่างปลอดภัยหรือไม่?
ฉันเพิ่งเข้าร่วมหลักสูตรออนไลน์เกี่ยวกับภาษาการเขียนโปรแกรมซึ่งมีการนำเสนอการปิด ฉันเขียนสองตัวอย่างที่ได้รับแรงบันดาลใจจากหลักสูตรนี้เพื่อให้บริบทก่อนถามคำถาม ตัวอย่างแรกคือฟังก์ชัน SML ที่สร้างรายการตัวเลขจาก 1 ถึง x โดยที่ x คือพารามิเตอร์ของฟังก์ชัน: fun countup_from1 (x: int) = let fun count (from: int) = if from = x then from :: [] else from :: count (from + 1) in count 1 end ใน SML REPL: val countup_from1 = fn : int …

7
ผู้ประกอบการมีความชัดเจนในการอ่านมากกว่าคำหลักหรือฟังก์ชั่น? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา มันเป็นอัตวิสัยเล็กน้อย แต่ฉันหวังว่าจะได้รับความเข้าใจที่ชัดเจนขึ้นว่าปัจจัยใดที่ทำให้ผู้ปฏิบัติงานชัดเจนในการใช้กับป้านและยาก ฉันกำลังพิจารณาการออกแบบภาษาเมื่อเร็ว ๆ นี้และสิ่งหนึ่งที่ฉันมักจะวนเวียนอยู่รอบ ๆ คือเมื่อใดที่จะทำให้การดำเนินงานที่สำคัญบางอย่างในภาษาเป็นผู้ดำเนินการและเมื่อใช้คำหลักหรือฟังก์ชั่น Haskell ค่อนข้างมีชื่อเสียงในเรื่องนี้เนื่องจากตัวดำเนินการแบบกำหนดเองนั้นง่ายต่อการสร้างและบ่อยครั้งที่ชนิดข้อมูลใหม่จะมาพร้อมกับตัวดำเนินการหลายตัวเพื่อใช้กับมัน ยกตัวอย่างเช่นห้องสมุด Parsec มาพร้อมกับตัวดำเนินการมากมายสำหรับการรวมตัวแยกวิเคราะห์เข้าด้วยกันด้วยอัญมณี>.และ.> ฉันจำไม่ได้ว่าพวกเขาหมายถึงอะไรในตอนนี้ แต่ฉันจำได้ว่าพวกเขาทำงานได้ง่ายมาก พวกเขาหมายถึงจริง ฟังก์ชั่นการโทรเช่นleftCompose(parser1, parser2)นี้ดีขึ้นหรือไม่ แน่นอนมากขึ้น verbose แต่ชัดเจนในบางวิธี ตัวดำเนินการโอเวอร์โหลดในภาษา C เหมือนเป็นปัญหาที่คล้ายกัน แต่ conflated โดยปัญหาเพิ่มเติมของการบรรทุกเกินพิกัดความหมายของผู้ประกอบการที่คุ้นเคยเช่น+ความหมายใหม่ที่ผิดปกติ ในภาษาใหม่ใด ๆ ดูเหมือนว่าจะเป็นปัญหาที่ค่อนข้างยาก ยกตัวอย่างเช่นใน F # การคัดเลือกนักแสดงใช้ตัวดำเนินการแคสติ้งประเภทที่ได้มาในเชิงคณิตศาสตร์แทนที่จะใช้ไวยากรณ์ของการส่งรูปแบบ C # หรือสไตล์ VB verbose C #: (int32) xVB: …

2
เหตุใดไฟล์ต้นฉบับ Java จึงมีชื่อของคลาสสาธารณะที่มีอยู่
ฉันเป็นมือใหม่ในการเรียนรู้จาวา ใน Java ไฟล์ต้นฉบับทุกไฟล์ต้องมีคลาสสาธารณะและไฟล์ต้นฉบับนั้นควรมีชื่อเดียวกันกับคลาสสาธารณะนั้น นอกจากนี้ไฟล์ต้นฉบับไม่สามารถมีสองคลาสสาธารณะ ทำไมข้อ จำกัด นี้?

6
เป็นไปได้หรือไม่ที่จะออกแบบภาษาที่ไม่มีข้อผิดพลาดทางไวยากรณ์? [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน9 ปีที่ผ่านมา ในคำอื่น ๆ ภาษาที่ทุกสายที่เป็นไปได้คือไวยากรณ์ที่ถูกต้อง? แก้ไข : นี่คือคำถามเชิงทฤษฎี ฉันไม่มีความสนใจในการใช้ภาษาดังกล่าว ฉันแค่ถามว่ามันเป็นไปได้ แก้ไขเพิ่มเติม ฉันไปข้างหน้าภาษาดังกล่าวที่ออกแบบมา ดูErrorFree

11
หลักการ KISS นำไปใช้กับการออกแบบภาษาการเขียนโปรแกรม?
KISS ("ทำให้มันง่ายโง่" หรือ "ทำให้มันง่าย ๆ โง่ ๆ ", ดูตัวอย่างที่นี่ ) เป็นหลักการสำคัญในการพัฒนาซอฟต์แวร์แม้ว่ามันจะมีต้นกำเนิดมาจากวิศวกรรม อ้างถึงจากบทความวิกิพีเดีย: หลักการนี้เป็นตัวอย่างที่ดีที่สุดโดยเรื่องราวของจอห์นสันส่งทีมวิศวกรออกแบบพร้อมเครื่องมือจำนวนหนึ่งด้วยความท้าทายที่เครื่องบินเจ็ทที่พวกเขากำลังออกแบบต้องได้รับการซ่อมโดยช่างทั่วไปในสนามรบภายใต้เงื่อนไขการต่อสู้ด้วยเครื่องมือเหล่านี้เท่านั้น ดังนั้น 'โง่' หมายถึงความสัมพันธ์ระหว่างวิธีที่สิ่งต่าง ๆ แตกหักและความซับซ้อนที่มีอยู่เพื่อแก้ไข หากฉันต้องการนำสิ่งนี้ไปใช้ในด้านการพัฒนาซอฟต์แวร์ฉันจะแทนที่ "เครื่องบินเจ็ท" ด้วย "ชิ้นส่วนของซอฟต์แวร์", "ช่างทั่วไป" กับ "นักพัฒนาเฉลี่ย" และ "ภายใต้เงื่อนไขการต่อสู้" กับ "ภายใต้การพัฒนา / บำรุงรักษาซอฟต์แวร์ เงื่อนไข "(กำหนดเวลา, ข้อ จำกัด ด้านเวลา, การประชุม / การขัดจังหวะ, เครื่องมือที่มีให้และอื่น ๆ ) ดังนั้นจึงเป็นความคิดที่ยอมรับกันโดยทั่วไปว่าควรพยายามเก็บชิ้นส่วนของซอฟต์แวร์ที่เรียบง่าย (หรือโง่อย่างง่ายในกรณีที่คุณไม่ใส่เครื่องหมายจุลภาค) เพื่อให้สามารถทำงานได้ในภายหลัง แต่หลักการ KISS สามารถนำไปใช้กับการออกแบบภาษาโปรแกรมได้หรือไม่ คุณรู้ภาษาการเขียนโปรแกรมใด ๆ …

1
เหตุใดการผนวกรายการใน Scala จึงมีความซับซ้อนของเวลา O (n)
ฉันเพิ่งอ่านว่าเวลาดำเนินการของการดำเนินการผนวกสำหรับList(+) Listเติบโตขึ้นเป็นเส้นตรงกับขนาดของ การต่อท้ายListดูเหมือนจะเป็นการดำเนินการทั่วไปที่ค่อนข้างสวย เหตุใดจึงควรใช้วิธีการนี้เพื่อเตรียมส่วนประกอบจากนั้นจึงย้อนรายการ มันไม่สามารถเป็นความล้มเหลวในการออกแบบเนื่องจากการใช้งานอาจเปลี่ยนแปลงได้ทุกเมื่อ จากมุมมองของฉันทั้งการเตรียมและการต่อท้ายควรเป็น O (1) มีเหตุผลที่ถูกต้องสำหรับสิ่งนี้หรือไม่?

2
ทำไมประเภทตัวเลือก Scala ไม่ถูกเรียกว่าอาจจะเหมือนกับใน Haskell [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ทำไมประเภทตัวเลือก Scala ไม่ถูกเรียกว่าอาจจะเหมือนกับใน Haskell อาจทำให้รู้สึก "ความหมาย" มากขึ้นสำหรับฉัน แต่บางทีตัวเลือกอาจมีพฤติกรรมที่แตกต่างกันซึ่งฉันไม่ทราบ มีเหตุผลใดเป็นพิเศษหรือไม่ที่ตัวเลือกใน Scala ไม่ได้ถูกเรียกว่าอาจจะ?

2
C ++ มีวิธีจัดการหลายมรดกด้วยบรรพบุรุษร่วมกันอย่างไร
ฉันไม่ใช่คน C ++ แต่ฉันถูกบังคับให้คิดเกี่ยวกับเรื่องนี้ เหตุใดจึงมีการสืบทอดหลายรายการใน C ++ แต่ไม่ใช่ใน C # (ฉันรู้ปัญหาเพชรแต่นั่นไม่ใช่สิ่งที่ฉันถามที่นี่) C ++ แก้ไขความคลุมเครือของลายเซ็นวิธีที่เหมือนกันซึ่งสืบทอดมาจากคลาสพื้นฐานหลายคลาสได้อย่างไร และทำไมการออกแบบเดียวกันไม่รวมอยู่ใน C #

2
ข้อดีและข้อเสียของการสร้างโค้ดทั้งหมดผ่านคลาสและคอมไพล์ไปยังคลาส (เช่น Java)
แก้ไข: ภาษาของฉันอนุญาตให้มีการสืบทอดหลายครั้งซึ่งแตกต่างจาก Java ฉันเริ่มออกแบบและพัฒนาภาษาโปรแกรมของฉันเองเพื่อวัตถุประสงค์ด้านการศึกษาการพักผ่อนหย่อนใจและอาจเป็นประโยชน์ ตอนแรกฉันตัดสินใจที่จะปิด Java นี่หมายความว่ารหัสทั้งหมดจะถูกเขียนในรูปแบบของคลาสและรหัสนั้นคอมไพล์ลงในคลาสซึ่งโหลดโดย VM อย่างไรก็ตามฉันได้ยกเว้นคุณสมบัติเช่นอินเทอร์เฟซและคลาสนามธรรมเพราะฉันไม่ต้องการมัน ดูเหมือนว่าพวกเขาจะบังคับกระบวนทัศน์และฉันต้องการให้ภาษาของฉันไม่ทำเช่นนั้น ฉันต้องการให้ชั้นเรียนเป็นหน่วยการรวบรวมเพราะดูเหมือนว่าจะสะดวกในการติดตั้งคุ้นเคยและฉันชอบความคิด จากนั้นฉันสังเกตเห็นว่าโดยทั่วไปแล้วฉันจะเหลืออยู่กับระบบโมดูลซึ่งสามารถใช้คลาสเป็น "เนมสเปซ" ได้โดยให้ค่าคงที่และฟังก์ชันโดยใช้staticคำสั่งหรือเป็นเทมเพลตสำหรับวัตถุที่ต้องมีอินสแตนซ์ ในภาษาอื่น ๆ ) ตอนนี้ฉันก็ยังสงสัยว่าอะไรคือ Upside และ Downside ของการมีคลาสเป็นหน่วยการคอมไพล์ นอกจากนี้ความเห็นทั่วไปเกี่ยวกับการออกแบบของฉันก็จะได้รับการชื่นชมมาก โพสต์ข้อมูลเกี่ยวกับภาษาของฉันสามารถพบได้ที่นี่: http://www.yannbane.com/2012/12/kava.html

5
ประโยชน์ของ OOP แบบคลาสสิกในภาษา Go-like
ฉันคิดถึงการออกแบบภาษาเป็นอย่างมากและองค์ประกอบใดบ้างที่จำเป็นสำหรับภาษาการเขียนโปรแกรม "อุดมคติ" และการศึกษา Go's ของ Google ทำให้ฉันตั้งคำถามกับความรู้ทั่วไปหลายอย่าง ดูเหมือนว่า Go จะได้รับประโยชน์ที่น่าสนใจทั้งหมดจากการเขียนโปรแกรมเชิงวัตถุโดยไม่มีโครงสร้างของภาษาเชิงวัตถุ ไม่มีคลาส, โครงสร้างเท่านั้น; ไม่มีการสืบทอดคลาส / โครงสร้าง - การฝังโครงสร้างเท่านั้น ไม่มีลำดับชั้นไม่มีคลาสพาเรนต์ไม่มีการปรับใช้อินเตอร์เฟสที่ชัดเจน กฎการคัดเลือกนักแสดงประเภทนั้นขึ้นอยู่กับระบบที่หลวมคล้ายกับการพิมพ์เป็ดเช่นหาก struct ดำเนินองค์ประกอบที่จำเป็นของ "Reader" หรือ "Request" หรือ "Encoding" คุณจะสามารถใช้และใช้มันได้ หนึ่งเดียว. มีบางอย่างเกี่ยวกับ OOP ที่ถูกนำมาใช้ใน C ++ และ Java และ C # ที่มีความสามารถมากขึ้นโดยทั่วไปมีความสามารถในการบำรุงรักษามากขึ้นและมีประสิทธิภาพมากกว่าที่คุณต้องยอมแพ้เมื่อย้ายไปใช้ภาษาอย่าง Go? คุณมีประโยชน์อะไรที่ต้องยอมแพ้เพื่อให้ได้ความเรียบง่ายที่กระบวนทัศน์ใหม่นี้แสดงให้เห็น? EDIT ลบคำถาม "ล้าสมัย" ที่ผู้อ่านดูเหมือนจะถูกวางสายเกินไปและทำให้โกรธโดย คำถามคืออะไรกระบวนทัศน์เชิงวัตถุแบบดั้งเดิม (ที่มีลำดับชั้นและเช่นนั้น) ที่เห็นบ่อยในการใช้ภาษาทั่วไปต้องเสนอที่ไม่สามารถทำได้อย่างง่ายดายในแบบจำลองที่ง่ายกว่านี้? หรืออีกนัยหนึ่งถ้าคุณต้องออกแบบภาษาวันนี้มีเหตุผลที่คุณต้องการรวมแนวคิดของลำดับชั้นของชั้นเรียนหรือไม่?

4
Ruby ทำอะไรได้ถูกต้อง (หรือเป็น Rails) [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ภาษาโปรแกรมส่วนใหญ่มีการตัดสินใจออกแบบที่มีผลต่อการใช้งานและการบังคับใช้ ตัวอย่างเช่น: Python มุ่งเน้นไปที่การบำรุงรักษา / ความสามารถในการอ่านของรหัสและมีการเยื้องเป็นส่วนหนึ่งของภาษาเอง ความตั้งใจของ Java คือการข้ามแพลตฟอร์ม OOP 'ง่ายขึ้น' และ 'เป็นมิตร' กว่า C ++ Objective-C ถูกสร้างขึ้นเพื่อเป็นตัวคลุม OO รอบ C ซึ่งไม่รู้อนาคตของ C ++ ในเวลานั้น Erlang ได้รับการออกแบบสำหรับระบบที่ทนต่อความผิดพลาดสูงและเกิดขึ้นพร้อมกัน PHP ออกแบบมาเพื่อจัดการการสร้างเว็บเพจแบบไดนามิก CoffeeScript ออกแบบมาเพื่อให้เห็นส่วนที่ดีของ Javascript และเพิ่ม OOP syntactical sugar และซ่อนความแตกต่าง (กลม ฯลฯ ) ของ JS 'เบื้องหลัง' …

5
มีจุดประสงค์เฉพาะสำหรับรายการต่างกันหรือไม่?
มาจากพื้นหลัง C # และ Java ฉันคุ้นเคยกับรายการของฉันที่เป็นเนื้อเดียวกันและนั่นสมเหตุสมผลสำหรับฉัน เมื่อฉันเริ่มยก Lisp ฉันสังเกตเห็นว่ารายการต่างกัน เมื่อฉันเริ่มที่จะวนรอบด้วยdynamicคำสำคัญใน C # ฉันสังเกตว่าใน C # 4.0 อาจมีรายการที่ต่างกันเช่นกัน: List<dynamic> heterogeneousList คำถามของฉันคือประเด็นอะไร ดูเหมือนว่ารายการต่างกันจะมีค่าใช้จ่ายมากขึ้นเมื่อทำการประมวลผลและถ้าคุณต้องการจัดเก็บประเภทที่แตกต่างกันในที่เดียวคุณอาจต้องใช้โครงสร้างข้อมูลที่แตกต่างกัน ความไร้เดียงสาของฉันคือการเลี้ยงใบหน้าที่น่าเกลียดหรือมีช่วงเวลาที่เป็นประโยชน์เมื่อมีรายการที่ต่างกันหรือไม่?

3
ทำไมคุณต้อง“ ตัวเอง” ใน Python เพื่ออ้างถึงตัวแปรอินสแตนซ์?
ฉันเขียนโปรแกรมเป็นภาษาต่างๆเช่น Java, Ruby, Haskell และ Python ฉันต้องสลับไปมาระหว่างหลายภาษาต่อวันเนื่องจากโครงการที่ฉันทำงานอยู่ ตอนนี้ปัญหาคือฉันมักจะลืมที่จะเขียนselfเป็นพารามิเตอร์แรกในนิยามฟังก์ชั่นใน Python เดียวกันกับวิธีการโทรบนวัตถุเดียวกัน ที่กล่าวว่าฉันค่อนข้างประหลาดใจกับวิธีการของ Python นี้ โดยทั่วไปเราต้องพิมพ์ให้มากขึ้นเพื่อทำสิ่งต่าง ๆ ในภาษาอย่าง Java และ Ruby สิ่งต่าง ๆ ทำได้ง่ายโดยอ้างอิงตัวแปรในวัตถุปัจจุบันโดยอัตโนมัติ คำถามของฉันคือเหตุใดจึงselfจำเป็น มันเป็นตัวเลือกสไตล์อย่างหมดจดหรือมีสาเหตุที่ Python ไม่สามารถให้คุณละเว้นselfวิธีที่ Java และ C ++ ปล่อยให้คุณละเว้นได้this?

1
ทำส่วนขยาย C เด่นใด ๆ รวมถึงประเภทจำนวนเต็มซึ่งพฤติกรรมไม่ขึ้นอยู่กับขนาดของเครื่องคำ
คุณลักษณะที่น่าสนใจของ C เมื่อเทียบกับภาษาอื่น ๆ คือประเภทข้อมูลจำนวนมากนั้นขึ้นอยู่กับขนาดของคำของสถาปัตยกรรมเป้าหมายแทนที่จะถูกระบุในเงื่อนไขแบบสัมบูรณ์ แม้ว่าสิ่งนี้จะช่วยให้ภาษาสามารถใช้ในการเขียนโค้ดบนเครื่องที่อาจมีปัญหากับบางประเภท แต่ก็เป็นการยากที่จะออกแบบรหัสซึ่งจะทำงานอย่างต่อเนื่องในสถาปัตยกรรมที่แตกต่างกัน พิจารณารหัส: uint16_t ffff16 = 0xFFFF; int64_t who_knows = ffff16 * ffff16; ในสถาปัตยกรรมที่intมี 16 บิต (ยังคงเป็นจริงของไมโครคอนโทรลเลอร์ขนาดเล็กจำนวนมาก) รหัสนี้จะกำหนดค่า 1 โดยใช้พฤติกรรมที่กำหนดไว้อย่างดี บนเครื่องที่intมี 64 บิตก็จะกำหนดค่า 4294836225 อีกครั้งโดยใช้พฤติกรรมที่กำหนดไว้อย่างดี บนเครื่องที่intมี 32 บิตก็น่าจะกำหนดค่า -131071 (ฉันไม่ทราบว่าจะเป็นพฤติกรรมการใช้งานที่กำหนดหรือไม่ได้กำหนด) แม้ว่าโค้ดจะไม่ใช้สิ่งใดนอกจากสิ่งที่ควรจะเป็นในนาม "ประเภทขนาดคงที่" มาตรฐานจะกำหนดให้คอมไพเลอร์สองแบบที่ใช้กันในวันนี้จะให้ผลลัพธ์ที่แตกต่างกันสองแบบและคอมไพเลอร์ยอดนิยมจำนวนมากในปัจจุบัน ตัวอย่างนี้เป็นการประดิษฐ์ที่ฉันไม่คาดหวังในรหัสโลกแห่งความจริงเพื่อกำหนดผลิตภัณฑ์ของค่า 16 บิตสองค่าโดยตรงกับค่า 64- บิต แต่มันถูกเลือกเป็นตัวอย่างสั้น ๆ เพื่อแสดงจำนวนเต็มสามวิธี การส่งเสริมการขายอาจโต้ตอบกับประเภทที่ไม่ได้ลงชื่อขนาดคงที่ มีสถานการณ์ในโลกจริงบางอย่างที่จำเป็นสำหรับการคำนวณทางคณิตศาสตร์ในประเภทที่ไม่ได้ลงนามตามกฎของเลขคณิตเลขจำนวนเต็มทางคณิตศาสตร์อื่น ๆ ที่จำเป็นที่จะต้องดำเนินการตามกฎของเลขคณิตแบบแยกส่วนและบางอย่างที่มันไม่จริง …

9
กฎข้อที่สิบของ Greenspun ทุกโครงการขนาดใหญ่มีล่ามเสียงกระเพื่อมหรือไม่? [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา กฎที่สิบของ Greenspun (จริงๆแล้วเป็นเพียงกฎเดียว) ระบุว่า: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. ความทรงจำของฉันคือว่ามีเอกสารบางอย่างในหัวข้อบางทีสำหรับโครงการ Quattro (สเปรดชีต) ของ Borland และอื่น ๆ Google ไม่มีความช่วยเหลือบางทีคำค้นหาที่ถูกต้องอาจไม่เป็นที่สนใจ ฉันกำลังมองหาเอกสารหรือบทความที่สนับสนุนการอ้างสิทธิ์นี้หากมี

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.