Информация об изменениях

Сообщение Re[10]: Опциональные типы от 27.02.2017 12:37

Изменено 27.02.2017 12:38 vdimas

Re[10]: Опциональные типы
Здравствуйте, VladD2, Вы писали:

V>>Кстате, смотрю в Java 8 добавили Optional и в нём та-да-ам:
V>>
V>>opt.ifPresent( x -> System.out.println("found " + x));
V>>

VD>Как же так? По твоей же теории в не функциональном языке без вариантов такое невозможно!
Не надо меня перевирать:

Поэтому, в ООП стиле "окончательно правильно" можно только так:

Optional<MyType> optional = getValueFromSomewhere();
optional.tryExtract(extractedValue => { /* callback */ });



V>>Или можно взглянуть сюда:
V>>
V>>public T ValueOr(T alternative) => hasValue ? value : alternative;
V>>

VD>Ой! Твоя теория распадается? Или ты все же решил признать очевидное?

Опять не надо меня перевирать:

Даже взять извлечение дефолтного значения, вот это правильный код (option[T]):

    public WithDefault (val : T) : T
    {
      match (this) {
        | Some (v) => v
        | None => val
      }
    }


А вот за это руки поотрывать и отлучать от программирования на веки вечные (ValueOption[T]): 
public GetValueOrDefault() : T { _value }



VD>Не. Ты с самого начала был не прав и (похоже) уже это осознал. Но пока не готов признать свою ошибку и пытаешься выкрутиться.

Я жду указания на мою ошибку.
А так же ответов на претензии технического плана.


VD>Советую тебе научиться признавать свою неправоту. В этом нет ничего зазорного. Наоборот, вот такие вот попытки выкрутиться выглядят намного хуже.

Покажи попытку выкрутиться.


VD>Все твои утверждения были ложными. А именно:
VD>1. Option спокойно можно реализовать в виде Value-типа. Это собственно доказано реализацией из Немерла.

Варианты вполне могут быть value-типами.
Я утверждал, что в ФП варианты чаще делают ссылочными типами — и на это есть причины.

И да. У тебя там не вариант.


VD>2. Варианты (они же: размеченные объединения, tagged unions, discriminated unions, disjoint union, sum type) можно реализовать в виде Value-типов.

Не утверждалось что нельзя.
Тем более, что я рядом сам показал, что CORBA и COM IDL генерят для С++ варианты как просто структуры.
Но в этом языке размеченные объединения не поддерживаются.


VD>3. Варианты спокойно могут быть в не функциональном языке. И вообще понятие функционального языка очень размытое.

Могут. Но безопасный интерфейс к ним я показал — через колбэк.
Считай, что ПМ в функциональных языках — это точно такой же колбэк, эдакая "лямбда", захватывающая текущий контекст, вызываемая с разресолвленными переменными-аргументами ПМ.


VD>4. Паттерн матчинг (ПМ) возможен не только вариантам, но и по любым типам.

С открытой структурой.
Иначе это будет просто сахар над цепочкой if-else-if...


VD>Причем типы даже не обязаны быть полиморфными, так как ПМ может проверять структуру типа (значения его членов).

Полиморфный или нет тут ортогонально.


VD>Все твои придирки к конкретным реализациям не более чем попытка увести разговор в строну.

В сторону ОТ ЧЕГО?
Я задвинул, что вот это зло:
    public Value : T
    {
      get
      {
        if (HasValue) _value 
        else assert(false, "try use Value when it not set");
      }
    }

Немерле тут не при чём.
Это точно такое же зло в любом языке, будь то C#, Java или С++.

И я совершенно не собираюсь уводить разговор в сторону от этого, а стою на своём — аналогом ПМ для ООП являются колбэки.
Но ввиду "тяжеловесности" этой техники, она была ранее не популярна.
Наверно поэтому и не был популярна в ООП идиома Optional.


VD>Убери те члены которые тебе не нравятся и ровным счетом ничего не изменится.

Если убрать одни члены, добавить другие, то изменится код вокруг таких типов, станет более безопасным, меньше простора для ошибок.


VD>Ну, а синтаксически все это можно завернуть в операторы или другие фичи языка.

Да, но я и тут сделал замечания:
1. В квадратных скобках лежит нечто плохочитаемое:
[ExtensionPattern(VSome(value) = ValueOption where(HasValue=true, Value=value))]
[ExtensionPattern(VNone()      = ValueOption where(HasValue=false))]
public struct ValueOption[T]

Действительно ли невозможно придумать более читабельный синтаксис?

2. Спросил, что будет в ситуации (None, None):
def Plus(x : optin[int], y : optin[int])
{
  | (Some(x), None)    => x
  | (None,    Some(y)) => y
  | (Some(x), Some(y)) => x + y
}

Предположил, что компилятор ругаться не будет, а в рантайм вернется дефолтное значение (я Немерле не знаю).
Если я правильно предположил, то хотелось бы знать — ПОЧЕМУ?
Как раз тут мне хотелось бы быть не правым. ))
Re[10]: Опциональные типы
Здравствуйте, VladD2, Вы писали:

V>>Кстате, смотрю в Java 8 добавили Optional и в нём та-да-ам:
V>>
V>>opt.ifPresent( x -> System.out.println("found " + x));
V>>

VD>Как же так? По твоей же теории в не функциональном языке без вариантов такое невозможно!

Не надо меня перевирать:

Поэтому, в ООП стиле "окончательно правильно" можно только так:

Optional<MyType> optional = getValueFromSomewhere();
optional.tryExtract(extractedValue => { /* callback */ });



V>>Или можно взглянуть сюда:
V>>
V>>public T ValueOr(T alternative) => hasValue ? value : alternative;
V>>

VD>Ой! Твоя теория распадается? Или ты все же решил признать очевидное?

Опять не надо меня перевирать:

Даже взять извлечение дефолтного значения, вот это правильный код (option[T]):

    public WithDefault (val : T) : T
    {
      match (this) {
        | Some (v) => v
        | None => val
      }
    }


А вот за это руки поотрывать и отлучать от программирования на веки вечные (ValueOption[T]): 
public GetValueOrDefault() : T { _value }



VD>Не. Ты с самого начала был не прав и (похоже) уже это осознал. Но пока не готов признать свою ошибку и пытаешься выкрутиться.

Я жду указания на мою ошибку.
А так же ответов на претензии технического плана.


VD>Советую тебе научиться признавать свою неправоту. В этом нет ничего зазорного. Наоборот, вот такие вот попытки выкрутиться выглядят намного хуже.

Покажи попытку выкрутиться.


VD>Все твои утверждения были ложными. А именно:
VD>1. Option спокойно можно реализовать в виде Value-типа. Это собственно доказано реализацией из Немерла.

Варианты вполне могут быть value-типами.
Я утверждал, что в ФП варианты чаще делают ссылочными типами — и на это есть причины.

И да. У тебя там не вариант.


VD>2. Варианты (они же: размеченные объединения, tagged unions, discriminated unions, disjoint union, sum type) можно реализовать в виде Value-типов.

Не утверждалось что нельзя.
Тем более, что я рядом сам показал, что CORBA и COM IDL генерят для С++ варианты как просто структуры.
Но в этом языке размеченные объединения не поддерживаются.


VD>3. Варианты спокойно могут быть в не функциональном языке. И вообще понятие функционального языка очень размытое.

Могут. Но безопасный интерфейс к ним я показал — через колбэк.
Считай, что ПМ в функциональных языках — это точно такой же колбэк, эдакая "лямбда", захватывающая текущий контекст, вызываемая с разресолвленными переменными-аргументами ПМ.


VD>4. Паттерн матчинг (ПМ) возможен не только вариантам, но и по любым типам.

С открытой структурой.
Иначе это будет просто сахар над цепочкой if-else-if...


VD>Причем типы даже не обязаны быть полиморфными, так как ПМ может проверять структуру типа (значения его членов).

Полиморфный или нет тут ортогонально.


VD>Все твои придирки к конкретным реализациям не более чем попытка увести разговор в строну.

В сторону ОТ ЧЕГО?
Я задвинул, что вот это зло:
    public Value : T
    {
      get
      {
        if (HasValue) _value 
        else assert(false, "try use Value when it not set");
      }
    }

Немерле тут не при чём.
Это точно такое же зло в любом языке, будь то C#, Java или С++.

И я совершенно не собираюсь уводить разговор в сторону от этого, а стою на своём — аналогом ПМ для ООП являются колбэки.
Но ввиду "тяжеловесности" этой техники, она была ранее не популярна.
Наверно поэтому и не был популярна в ООП идиома Optional.


VD>Убери те члены которые тебе не нравятся и ровным счетом ничего не изменится.

Если убрать одни члены, добавить другие, то изменится код вокруг таких типов, станет более безопасным, меньше простора для ошибок.


VD>Ну, а синтаксически все это можно завернуть в операторы или другие фичи языка.

Да, но я и тут сделал замечания:
1. В квадратных скобках лежит нечто плохочитаемое:
[ExtensionPattern(VSome(value) = ValueOption where(HasValue=true, Value=value))]
[ExtensionPattern(VNone()      = ValueOption where(HasValue=false))]
public struct ValueOption[T]

Действительно ли невозможно придумать более читабельный синтаксис?

2. Спросил, что будет в ситуации (None, None):
def Plus(x : optin[int], y : optin[int])
{
  | (Some(x), None)    => x
  | (None,    Some(y)) => y
  | (Some(x), Some(y)) => x + y
}

Предположил, что компилятор ругаться не будет, а в рантайм вернется дефолтное значение (я Немерле не знаю).
Если я правильно предположил, то хотелось бы знать — ПОЧЕМУ?
Как раз тут мне хотелось бы быть не правым. ))