Kotlin vs Option Type

6yrop

В продолжение к вот этому
Явное указание nullable типов это, конечно, хорошо сделали. Но это не исключает использование Option Type, поскольку Option Type может иметь рекурсивную вложенность. Например, что возвращает словарь, если в нем лежат option integer? При использовании Option Type всё очевидно, возвращается Option<Option<int>>.

kokoc88

Явное указание nullable типов это, конечно, хорошо сделали. Но это не исключает использование Option Type, поскольку Option Type может иметь рекурсивную вложенность. Например, что возвращает словарь, если в нем лежат option integer? При использовании Option Type всё очевидно, возвращается Option<Option<int>>.

В очередной раз прочитал пост Шуреска и вдруг отчётливо представил себе мучительный процесс, который происходит у таких вот кодеров. Например, нужно человеку сделать массив int[], и не может, не может он просто так взять и написать "int[] array", ибо терзают его угрызения духовные и всякие другие. И сидит он, и думает час, другой, третий; и городит скобочки фигурные и простые, и стирает их, и пишет заново. И так не получается у него, и эдак. Вдруг проходит день, неделя, и вместо простого массива появляется на свет безумная для людей, но милая Шуреску обёрнутая обёртка над обёрткой обёрток. И простая, казалось бы, задача начинает жить своей жизнью, и даже процессор в компьютере начинает как бы страдать вместе с Шуреском, выполняя сложения не за один простецкий такт, а за десятки безопасных и учёных тактов.

katrin2201

В твоем вырожденном случае не очень непонятно, зачем нужна подобная конструкция.
Тем не менее, и ее можно достичь введением нового класса, скажем, DictionaryElement, в котором полем будет int?. Тогда в свою очередь можно будет делать DictionaryElement?.
Ну и да, плюсуюсь к злобному сарказму Майка =)

6yrop

В твоем вырожденном случае не очень непонятно, зачем нужна подобная конструкция.

ты не можешь представить ситуацию, когда в словарь складываются nullable целые числа? :confused:

Тем не менее, и ее можно достичь введением нового класса, скажем, DictionaryElement, в котором полем будет int?. Тогда в свою очередь можно будет делать DictionaryElement?.

Можно, но много писанины, за которой сложно проследить, собственно, что делаем.

Ну и да, плюсуюсь к злобному сарказму Майка =)

Я его игнорю, поэтому не знаю, что он там пишет.

katrin2201

> ты не можешь представить ситуацию, когда в словарь складываются nullable целые числа? :confused:

Майк заметил, что для такой вещи у тебя скорее будет что-то вроде Set<Option<Int>>.
Ну и да, смысловая нагрузка хранения в словаре null элементов мне неясна. Я бы их выфильтровывал, и просто возвращал Set<Int>.
> Можно, но много писанины, за которой сложно проследить, собственно, что делаем.
Писанины больше, зато сторонний наблюдатель сломает голову на твоих Option<Option<Builder<Factory<Factory<...>>>>>.
А в случае с DictionaryElement даже не задумается. Повышение уровня абстракции, все дела. Выводы делай сам.

6yrop

А в случае с DictionaryElement даже не задумается.

Ровно наоборот. Задумается, что это за хрень DictionaryElement, и зачем она тут вставлена.

Повышение уровня абстракции, все дела.

Как расположены эти два решения на шкале абстракций? Что ниже, что выше?

Builder<Factory<Factory<

Это вообще не о том. Слышал звон ....

6yrop

Майк заметил, что для такой вещи у тебя скорее будет что-то вроде Set<Option<Int>>.
Ну и да, смысловая нагрузка хранения в словаре null элементов мне неясна. Я бы их выфильтровывал, и просто возвращал Set<Int>.

Тип коллекции тут вообще не важен, рассматриваем любой метод поиска.

katrin2201

> Ровно наоборот. Задумается, что это за хрень DictionaryElement, и зачем она тут вставлена.
Думаю, продолжать дальше бессмысленно.
nb. Nullable тип - это фича языка. А твой Option type - либа. Ничто не мешает ее заиметь тебе где угодно, в том же Котлине, если тебе кажется таким уж идиотизмом каждый раз создавать класс с человеческим именем. Хотя, учитывая что ты сам всегда выступаешь за строгую типизацию, я несколько удивлен.

kokoc88

Майк заметил, что для такой вещи у тебя скорее будет что-то вроде Set<Option<Int>>.

О_о

6yrop

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

Но я так же за анонимные классы, круто же, когда из функции можно легко вернуть два значения:

 

function f {

    return { 

        A: "test",

        B: 1

   };

}

И это статически типизировано без "человеческих" имен. Часто тут как раз делают неудобные для человека имена, поскольку ничего другого не остается.

6yrop

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

Мой поинт: основная фишка статической типизации, что она оставляет связи между точками в исходном коде. А "человеческие" имена это не связанная вещь со статической типизацией. Я бы даже сказал, что в недоделанных статических языках получается нечеловечески многословно.

katrin2201

Option<Option<Int>> может быть элементами словаря. Может быть, там, не знаю, списком параметров к процедуре из недр твоего CQ.
Передать одно вместо другого должно быть нельзя, потому что это разные вещи. Если ты обзовешь это своими классами со своими человеческими именами - то компилятор схватит тебя за руку. Если оставишь либовый Option<Option<>>, то не схватит.

6yrop

Option<Option<Int>> может быть элементами словаря. Может быть, там, не знаю, списком параметров к процедуре из недр твоего CQ.
Передать одно вместо другого должно быть нельзя, потому что это разные вещи. Если ты обзовешь это своими классами со своими человеческими именами - то компилятор схватит тебя за руку. Если оставишь либовый Option<Option<>>, то не схватит.

Int может быть элементами словаря. Может быть, там, не знаю, списком параметров к процедуре из недр твоего CQ.
Передать одно вместо другого должно быть нельзя, потому что это разные вещи. Если ты обзовешь это своими классами со своими человеческими именами - то компилятор схватит тебя за руку. Если оставишь либовый Int, то не схватит.
Не?

6yrop

Не понимаю с чем ты споришь. Два вопросика написать нельзя "SomeType?", две Option можно "Option<Option<SomeType>>", в остальном вопросик и Option взаимозаменяемы. Зачем запрещать писать два вопросика?

katrin2201

Потому что вопросик не заворачивает во враппер исходный тип, а экстендит его :confused:

Два раза проэкстендить одним и тем же как-то бессмысленно...

6yrop

а все же, как через вопросик будет выглядить вот такой generic метод?

 

Option<T> First<T>(IEnumerable<T> arg) {

    ...

}

katrin2201

<T> public T? first(Set<T> arg);
еще можно написать
<T: Any> public T? first(Set<T> arg);
тогда T будет строго non-nullable

6yrop

<T> public T? first(Set<T> arg);

Вопрос к этому варианту.
Set<int?> x = ...
var y = first(x);
Какого типа будет y?

Dasar

Какого типа будет y?

по видимому не скомпилируется

6yrop

какая строчка не скомпилируется? создание коллекции типа <int?> или вызов метода first?

Dasar

извини, фигню спорол. не ту строчку взял за основу.

6yrop

если второе, то это же полный пипец, вот у меня есть коллекция, я по ней могу итерироваться, я написал метод, который заходит в итерацию и возвращает первый элемент. И бац, я не могу им воспользоваться? Ну бред же.

6yrop

<T> public T? first(Set<T> arg);
еще можно написать
<T: Any> public T? first(Set<T> arg);
тогда T будет строго non-nullable

А в реальности вот как криво и непоследовательо:

find
fun <T> Iterable<T>.find(predicate: (T) -> Boolean): T?
Returns the first element which matches the given predicate or null if none matched
first
fun <T> Iterable<T>.first: T
Get the first element in the collection.
Will throw an exception if there are no elements
http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/...

Метод find нельзя вызвать на коллекции типа <T?>. А метод fist можно. ЛОЛ :grin:

И как прозрачно и последовательно в Scala, где есть Option:

find(p: (A) ⇒ Boolean): Option[A]
Finds the first element of the iterable collection satisfying a predicate, if any.
p
the predicate used to test elements.
returns
an option value containing the first element in the iterable collection that satisfies p, or None if none exists.
head: A
Selects the first element of this iterable collection.
returns
the first element of this iterable collection.
Exceptions thrown
`NoSuchElementException`
if the iterable collection is empty.
headOption: Option[A]
Optionally selects the first element.
returns
the first element of this iterable collection if it is nonempty, None if it is empty.
http://www.scala-lang.org/api/current/index.html#scala.colle...

Тут видим:
1. Метод find доступный для всех коллекций.
2. Аналога метода headOption в Kotlin просто нет.

Оставить комментарий