อะไรคือแรงจูงใจสำหรับการมอบหมายงาน Scala ที่ประเมินเป็นหน่วยแทนที่จะเป็นค่าที่กำหนด
รูปแบบทั่วไปในการเขียนโปรแกรม I / O คือการทำสิ่งนี้:
while ((bytesRead = in.read(buffer)) != -1) { ...
แต่สิ่งนี้ทำไม่ได้ในสกาล่าเพราะ ...
bytesRead = in.read(buffer)
.. ส่งคืนหน่วยไม่ใช่ค่าใหม่ของ bytesRead
ดูเหมือนเป็นสิ่งที่น่าสนใจที่จะละเว้นจากภาษาที่ใช้งานได้ ฉันสงสัยว่าทำไมถึงทำเช่นนั้น?
คำตอบ:
ฉันสนับสนุนให้มีการมอบหมายคืนค่าที่กำหนดแทนที่จะเป็นหน่วย มาร์ตินกับฉันกลับไปกลับมา แต่ข้อโต้แย้งของเขาคือการใส่ค่าลงในสแต็กเพียงเพื่อให้มันหลุด 95% ของเวลานั้นเป็นการเสียไบต์โค้ดและส่งผลเสียต่อประสิทธิภาพ
voidผลตอบแทน ใน Scala foo_=(v: Foo)ควรส่งคืนFooหากได้รับมอบหมาย
void( Unit), การมอบหมายx = valueได้รับการแปลเทียบเท่าx.set(value);x.get(value); คอมไพลเลอร์จะกำจัดในการเพิ่มประสิทธิภาพเฟสget-calls หากไม่ได้ใช้ค่า อาจเป็นการเปลี่ยนแปลงที่น่ายินดีในรุ่นใหญ่ใหม่ (เนื่องจากความเข้ากันไม่ได้ย้อนหลัง) รุ่น Scala และการระคายเคืองน้อยลงสำหรับผู้ใช้ คุณคิดอย่างไร?
ฉันไม่ได้รับข้อมูลภายในเกี่ยวกับเหตุผลที่แท้จริง แต่ความสงสัยของฉันง่ายมาก Scala ทำให้ลูปที่มีผลข้างเคียงไม่สะดวกในการใช้งานดังนั้นโปรแกรมเมอร์จะชอบความเข้าใจโดยธรรมชาติ
มันทำได้หลายวิธี ตัวอย่างเช่นคุณไม่มีforลูปที่คุณประกาศและกลายพันธุ์ตัวแปร คุณไม่สามารถ (อย่างง่ายดาย) สถานะกลายพันธุ์บนwhileลูปในเวลาเดียวกันกับที่คุณทดสอบเงื่อนไขซึ่งหมายความว่าคุณมักจะต้องทำการผ่าเหล่าซ้ำก่อนหน้านี้และในตอนท้ายของมัน ตัวแปรที่ประกาศภายในwhileบล็อกจะมองไม่เห็นจากwhileเงื่อนไขการทดสอบซึ่งทำให้do { ... } while (...)มีประโยชน์น้อยกว่ามาก และอื่น ๆ
วิธีแก้ปัญหา:
while ({bytesRead = in.read(buffer); bytesRead != -1}) { ...
เพื่อสิ่งที่คุ้มค่า
ในฐานะที่เป็นคำอธิบายอื่น ๆ บางที Martin Odersky อาจต้องเผชิญกับข้อบกพร่องที่น่าเกลียดมากที่เกิดจากการใช้งานดังกล่าวและตัดสินใจที่จะผิดกฎหมายจากภาษาของเขา
แก้ไข
David Pollackได้ตอบด้วยข้อเท็จจริงที่เป็นจริงบางประการซึ่งได้รับการรับรองอย่างชัดเจนจากข้อเท็จจริงที่ว่าMartin Oderskyแสดงความคิดเห็นคำตอบของเขาโดยให้ความเชื่อถือในประเด็นที่เกี่ยวข้องกับการปฏิบัติงานโดย Pollack
forเวอร์ชันลูป: for (bytesRead <- in.read(buffer) if (bytesRead) != -1ซึ่งดีมากยกเว้นว่าจะใช้ไม่ได้เพราะไม่มีforeachและwithFilterพร้อมใช้งาน!
เหตุการณ์นี้เกิดขึ้นเนื่องจาก Scala มีระบบประเภทที่ "ถูกต้องอย่างเป็นทางการ" มากกว่า การพูดอย่างเป็นทางการการมอบหมายงานเป็นคำสั่งที่มีผลข้างเคียงอย่างUnitแท้จริงดังนั้นจึงควรกลับมา สิ่งนี้มีผลดีบางอย่าง ตัวอย่างเช่น:
class MyBean {
private var internalState: String = _
def state = internalState
def state_=(state: String) = internalState = state
}
state_=วิธีการส่งกลับUnit(ตามที่คาดว่าจะสำหรับหมา) Unitที่แม่นยำเพราะผลตอบแทนที่ได้รับมอบหมาย
ฉันยอมรับว่าสำหรับรูปแบบสไตล์ C เช่นการคัดลอกสตรีมหรือคล้ายกันการตัดสินใจออกแบบโดยเฉพาะนี้อาจเป็นเรื่องยุ่งยากเล็กน้อย อย่างไรก็ตามโดยทั่วไปแล้วมันค่อนข้างไม่มีปัญหาและก่อให้เกิดความสอดคล้องโดยรวมของระบบประเภท
อาจเป็นเพราะหลักการแยกคำสั่งคิวรี ?
CQS มีแนวโน้มที่จะได้รับความนิยมที่จุดตัดของ OO และรูปแบบการเขียนโปรแกรมเชิงฟังก์ชันเนื่องจากสร้างความแตกต่างที่ชัดเจนระหว่างวิธีการวัตถุที่ทำหรือไม่มีผลข้างเคียง (เช่นที่เปลี่ยนแปลงวัตถุ) การนำ CQS ไปใช้กับการกำหนดตัวแปรจะใช้เวลามากกว่าปกติ แต่ก็ใช้แนวคิดเดียวกัน
ภาพประกอบสั้น ๆ ว่าทำไม CQS เป็นประโยชน์: พิจารณาสมมุติไฮบริดภาษา F / OO กับListชั้นเรียนที่มีวิธีการSort, Append, และFirst Lengthในรูปแบบ OO ที่จำเป็นเราอาจต้องการเขียนฟังก์ชันเช่นนี้:
func foo(x):
var list = new List(4, -2, 3, 1)
list.Append(x)
list.Sort()
# list now holds a sorted, five-element list
var smallest = list.First()
return smallest + list.Length()
ในขณะที่รูปแบบการใช้งานมีแนวโน้มที่จะเขียนสิ่งนี้มากกว่า:
func bar(x):
var list = new List(4, -2, 3, 1)
var smallest = list.Append(x).Sort().First()
# list still holds an unsorted, four-element list
return smallest + list.Length()
สิ่งเหล่านี้ดูเหมือนจะพยายามทำในสิ่งเดียวกัน แต่เห็นได้ชัดว่าหนึ่งในสองอย่างนั้นไม่ถูกต้องและโดยไม่ทราบข้อมูลเพิ่มเติมเกี่ยวกับพฤติกรรมของวิธีการเราไม่สามารถบอกได้ว่าวิธีใด
อย่างไรก็ตามการใช้ CQS เราจะยืนยันว่าหากAppendและSortเปลี่ยนแปลงรายการพวกเขาจะต้องส่งคืนประเภทหน่วยดังนั้นจึงป้องกันไม่ให้เราสร้างจุดบกพร่องโดยใช้รูปแบบที่สองเมื่อเราไม่ควร ดังนั้นการปรากฏตัวของผลข้างเคียงจึงกลายเป็นนัยในลายเซ็นของวิธีการด้วย
ฉันเดาว่านี่คือเพื่อให้โปรแกรม / ภาษาปราศจากผลข้างเคียง
สิ่งที่คุณอธิบายคือการใช้ผลข้างเคียงโดยเจตนาซึ่งในกรณีทั่วไปถือเป็นสิ่งที่ไม่ดี
val a = b = 1(จินตนาการ "ขลัง" valในด้านหน้าของb) val a = 1; val b = 1;กับ
ไม่ใช่รูปแบบที่ดีที่สุดในการใช้การกำหนดเป็นนิพจน์บูลีน คุณทำสองสิ่งในเวลาเดียวกันซึ่งมักนำไปสู่ข้อผิดพลาด และหลีกเลี่ยงการใช้ "=" แทน "==" โดยไม่ได้ตั้งใจด้วยข้อ จำกัด ของ Scalas
โดยวิธีการ: ฉันพบว่า while-trick เริ่มต้นโง่แม้ใน Java ทำไมไม่คิดแบบนี้ล่ะ?
for(int bytesRead = in.read(buffer); bytesRead != -1; bytesRead = in.read(buffer)) {
//do something
}
จริงอยู่งานจะปรากฏขึ้นสองครั้ง แต่อย่างน้อย bytesRead อยู่ในขอบเขตที่เป็นของและฉันไม่ได้เล่นกับเทคนิคการมอบหมายที่ตลก ...
คุณสามารถมีวิธีแก้ปัญหานี้ได้ตราบเท่าที่คุณมีประเภทการอ้างอิงสำหรับทิศทาง ในการใช้งานที่ไร้เดียงสาคุณสามารถใช้สิ่งต่อไปนี้สำหรับประเภทที่กำหนดเอง
case class Ref[T](var value: T) {
def := (newval: => T)(pred: T => Boolean): Boolean = {
this.value = newval
pred(this.value)
}
}
จากนั้นภายใต้ข้อ จำกัด ที่คุณจะต้องใช้ref.valueเพื่อเข้าถึงข้อมูลอ้างอิงในภายหลังคุณสามารถเขียนเพรดิเคตของคุณwhileเป็น
val bytesRead = Ref(0) // maybe there is a way to get rid of this line
while ((bytesRead := in.read(buffer)) (_ != -1)) { // ...
println(bytesRead.value)
}
และคุณสามารถทำการตรวจสอบเทียบกับ bytesReadในลักษณะที่เป็นนัยมากขึ้นโดยไม่ต้องพิมพ์