Що є мотивацією для оцінки призначення Scala для Unit, а не присвоєного значення?

Що є мотивацією для оцінки призначення Scala для Unit, а не присвоєного значення?

Поширеною схемою програмування вводу-виводу є такі речі:

while ((bytesRead = in.read(buffer)) != -1) { ...

Але в Scala це неможливо, оскільки ...

bytesRead = in.read(buffer)

.. повертає Unit, а не нове значення bytesRead.

Здається цікавою річчю, яку можна залишити поза функціональною мовою. Цікаво, чому так було зроблено?

Я виступав за те, щоб присвоєння повертали значення, а не одиницю. Ми з Мартіном ходили туди-сюди, але його аргумент полягав у тому, що введення значення в стек лише для того, щоб його випустити 95% часу - це марнотратство байт-кодів і негативний вплив на продуктивність.

Я не знаю внутрішньої інформації про фактичні причини, але моя підозра дуже проста. Scala робить цикли з побічними ефектами незручними у використанні, так що програмісти, природно, віддадуть перевагу розумінням.

Це робиться різними способами. Наприклад, у вас немає forциклу, де ви оголошуєте та мутуєте змінну. Ви не можете (легко) мутувати стан whileциклу одночасно з тестуванням стану, а це означає, що вам часто доводиться повторювати мутацію безпосередньо перед нею та в кінці її. Змінні, оголошені всередині whileблоку, не видно з whileумови тесту, що робить do { ... } while (...)набагато менш корисним. І так далі.

Вирішення проблеми:

while ({bytesRead = in.read(buffer); bytesRead != -1}) { ... 

За все, що це варто.

Як альтернативне пояснення, можливо, Мартіну Одерському довелося зіткнутися з кількома дуже потворними помилками, що виникають внаслідок такого використання, і вирішив заборонити це з його мови.

РЕДАГУВАТИ

Девід Поллак вже відповів з деякими реальними фактами, які чітко підтверджено тим фактом , що Одерська сам прокоментував свою відповідь, даючи правдоподібність аргументу питання , пов'язані з продуктивністю , висунутої Поллак.

Це сталося в рамках Scala, що має більш "формально правильну" систему типу. Формально кажучи, доручення - це суто побічна заява, і тому воно має повернутися Unit. Це має кілька приємних наслідків; наприклад:

class MyBean {
  private var internalState: String = _

  def state = internalState

  def state_=(state: String) = internalState = state
}

У state_=методі повертає значення Unit(як можна було б очікувати для інкубатора) саме тому , що повертає призначення Unit.

Я погоджуюсь, що для шаблонів у стилі С, таких як копіювання потоку чи подібних, це конкретне рішення щодо дизайну може бути трохи складним. Однак це насправді відносно безпроблемно загалом і справді сприяє загальній послідовності системи типів.

Можливо, це пов'язано з принципом розділення командного запиту ?

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змінити список, вони повинні повернути тип одиниці, тим самим заважаючи нам створювати помилки, використовуючи другу форму, коли ми не повинні. Отже, наявність побічних ефектів також стає неявною у підписі методу.

Я думаю, це для того, щоб програма / мова не мала побічних ефектів.

Ви описуєте навмисне використання побічного ефекту, який у загальному випадку вважається поганим.

Використовувати призначення як логічний вираз - це не найкращий стиль. Ви виконуєте дві речі одночасно, що часто призводить до помилок. А випадкове використання "=" замість "==" уникається за допомогою обмеження Scalas.

До речі: я вважаю початковий трюк дурним навіть у 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більш неявно, без необхідності вводити його.