Здравствуйте, Klapaucius, Вы писали:

C>>

C>>z= (x!=null && y!=null) ? x + y : null;
C>>

K>У этого вашего "удобства" недетское злое лицо. Обычно такое "удобство" называют неудобством. Выделенный жирным шрифтом код совсем не нужен и писать такой код не нужно. Котлин же заставляет писать ненужный код. Это — практично?
Ну можно вот так:

z = x ?+? y

Разбирается так: x? +? (y). Т.е. x? — вернуть null, если x==null. Затем инфиксный метод +?, который вернёт null, если аргумент его равен null'у.

K>Ну, оператор ?. "поднимает" U -> V в "контекст" Nullable и мы получаем по факту Nullable<U> -> Nullable<V> ну или сокращенно U? -> V?. Все это, понятно, в кавычках, потому что он ничего такого он разумеется не делает — это ad-hoc костыль, потому что авторы Котлина не читатели и страдают синдромом Уолта Брайта. Но у читателя возникают некоторые ассоциации. И тут сразу возникает вопрос — а почему только Nullable<_>, а не любой другой функтор? Наверное, когда котлиностроители начнут вставлять в язык какое-нибудь асинхронное программирование они возьмут и вцементируют в язык какой-нибудь оператор ||. или что-то наподобие.
Ты говоришь так, как будто в этом что-то плохое.

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

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Diamond-проблему как раз трейты решают, и это решение модульное, типобезопасное и непротиворечивое (см. статью Scalable component abstractions). Соглашусь, что несколько громоздкое из-за правил линеаризации. И ограничения есть — нетривиальные конструкторы недопустимы. Впрочем, если мы хотим позволить себе конструкторы с параметрами, тогда придётся навернуть систему типов и отношений между классами.
Вот только оно неудобное. Конструкторы реально достают, к примеру.

Diamond-проблема на практике во многом надумана, она встречается раз в пятилетку. Поэтому стоит ввести какое-то поведение для неё, но не трогать самые частые случаи использования наследования — частичные mixin'ы.

LCR>А вот то что я вижу в Котлине вызывает ряд вопросов:
LCR>

LCR>open class A(virtual var v : int)
LCR>open class B(v : Int) : A(v)
LCR>open class C(v : Int) : A(v)

LCR>class D(v : Int) : B(v), C(v) {
LCR>  override var v : Int
LCR>    get() = this<B>.v
LCR>    set(value) { this<B>.v = value }
LCR>}
LCR>

LCR>1. Требуется ли всегда вручную явно указать как разрешать противоречия? (Если да, то печаль.)
Да.

LCR>2. Сколько подобъектов A содержится в D (если 2, то это грабли, и тогда эти сопли не нужны, лучше использовать композицию, если 1, то см ниже.)
LCR>3. Как будем инициализировать подобъект А если напишем
Пока неизвестно.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Это как раз случай простого и неправильного решения для сложной проблемы. Вообще, я понимаю, об окончательном решении сейчас рано говорить — язык ещё даже не оформлен, не то что не реализован. Но если эта залепуха (а по другому я это "решение" назвать не могу) останется в релизе, то это будет полнейший фэйспалм. Можно понять Страуструпа — он лепил из того, что было, и опыта хождения по граблям множественного наследования не было никакого. Гослинг (а вслед и Хейлсберг) посмотрели на это, и сказали — нафиг надо и ввели ограничения, так что выразительность упала значительно, но и грабли были убраны. А что мы видим здесь? возврат к старому и злому С++.

А кто тебе сказал, что они не учли грабли С++?

LCR>Diamond-проблему как раз трейты решают, и это решение модульное, типобезопасное и непротиворечивое (см. статью Scalable component abstractions).

По словам авторов, их решение тоже решает эту проблему. И решает очень просто.

Кроме МН они еще отказались от полей. Зачем? Да чтобы не иметь той самой проблемы бриллиантового наследования. Введя одно очень простое правило — если в нескольких супертипах есть члены с одинаковой сигнатурой (независимо от глубины вложенности), то в подтипе эти члены должны быть переопределены. В купе с отсутствием свойств — это решает проблему брилиантового наследования.

LCR>Соглашусь, что несколько громоздкое из-за правил линеаризации.

Вот и авторы Котлина так посчитали.

LCR>И ограничения есть — нетривиальные конструкторы недопустимы.

Что значит нетривиальные?

Ну, да наличие ограничений — это точно не плюс.

LCR> Впрочем, если мы хотим позволить себе конструкторы с параметрами, тогда придётся навернуть систему типов и отношений между классами.

Насколько я понимаю у этих орлов с конструкторами проблем быть не должно. Хотя нужно в этом разобраться.

LCR>Самый продвинутый известный мне вариант описан в статье CZ:MultipleInheritance Without Diamonds — а именно ввести 2 вида отношений: extends и requires, и разделить понятия subtype и subclass.

Дык, а не это ли делают интерфейсы и одиночное наследование?

LCR>А вот то что я вижу в Котлине вызывает ряд вопросов:
LCR>

LCR>open class A(virtual var v : int)
LCR>open class B(v : Int) : A(v)
LCR>open class C(v : Int) : A(v)

LCR>class D(v : Int) : B(v), C(v) {
LCR>  override var v : Int
LCR>    get() = this<B>.v
LCR>    set(value) { this<B>.v = value }
LCR>}
LCR>

LCR>1. Требуется ли всегда вручную явно указать как разрешать противоречия? (Если да, то печаль.)

В Котлине предлагается переопределять все конфликтующие по имени члены. В принципе разумное требование.

LCR>2. Сколько подобъектов A содержится в D (если 2, то это грабли, и тогда эти сопли не нужны, лучше использовать композицию, если 1, то см ниже.)

Как я понимаю — один.

LCR>3. Как будем инициализировать подобъект А если напишем
LCR>

LCR>open class A(virtual var v : int)
LCR>open class B(v : Int) : A(100)
LCR>open class C(v : Int) : A(200)

LCR>class D(v : Int) : B(v), C(v) { ... }
LCR>

LCR>Сколько раз будем вызывать конструктор для A? Я надеюсь, один раз, но тогда с каким аргументом? (Для Скалы пофиг, у всех трейтов одинаковые то бишь дефолтные конструкторы, поэтому выбор очевиден — вызываем один раз единственно имеющийся конструктор).

Вот это конечно большой вопрос. По идее вызов базового конструктора — это такой же конфликт, так что его нужно точно так же перекрывать.
В общем, надо звать сюда авторов и распрашивать.

LCR>Плюс, в Скале есть мембер-типы и селфтипы, что позволяет элегантно расправиться с Expression Problem. А Котлин?

Никогда не мог понять, что люди понимаю под этим термином.

Как я понимаю реально базовые классы за исключением первого преобразуются в интерфейсы.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Самый продвинутый известный мне вариант описан в статье CZ:MultipleInheritance Without Diamonds — а именно ввести 2 вида отношений: extends и requires, и разделить понятия subtype и subclass.
LCR>Вкратце, любые ромбы запрещены, но чтобы сохранить выразительность и переиспользовать функционал, можно ввести отношение requires: C requires A. Означает это, что C становится абстрактным, будет подтипом A (то есть можно приводить ссылки), и конкретные наследники C должны будут также наследовать и от A.

Почитал (бегло). Сдается мне, что описанное по ссылке решение и то что предлагают ДжетБрэйновцы, если не одно и то же, то очень близкие решения.

Здравствуйте, VladD2, Вы писали:

LCR>>2. Сколько подобъектов A содержится в D (если 2, то это грабли, и тогда эти сопли не нужны, лучше использовать композицию, если 1, то см ниже.)

VD>Как я понимаю — один.

Похоже я поторопился с ответом...

LCR>>3. Как будем инициализировать подобъект А если напишем
LCR>>

LCR>>open class A(virtual var v : int)
LCR>>open class B(v : Int) : A(100)
LCR>>open class C(v : Int) : A(200)

LCR>>class D(v : Int) : B(v), C(v) { ... }
LCR>>

LCR>>Сколько раз будем вызывать конструктор для A? Я надеюсь, один раз, но тогда с каким аргументом? (Для Скалы пофиг, у всех трейтов одинаковые то бишь дефолтные конструкторы, поэтому выбор очевиден — вызываем один раз единственно имеющийся конструктор).

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

В общем, стало еще интереснее выслушать объяснение авторов Котлина.

Здравствуйте, Cyberax, Вы писали:

C>Ну можно вот так...

Как можно, я думаю, все интересующиеся вопросом узнали. Только вот в Котлин, как я понимаю, нельзя, а авторы не особенно вопросами интересуются.

C>Ты говоришь так, как будто в этом что-то плохое.

Верно. И как раз потому, что в этом есть что-то плохое.

C>Я не против хорошо сделанного языка

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

C>со специальными случаями.

Вопрос в том, где остановится со всем этим ползучим частнослученизмом. А то умножать, например, целые числа оператором *, а числа с плавающей точкой — PLEASE MULTIPLY удовольствие сомнительное.

Здравствуйте, Klapaucius, Вы писали:

C>>Ну можно вот так...
K>Как можно, я думаю, все интересующиеся вопросом узнали. Только вот в Котлин, как я понимаю, нельзя, а авторы не особенно вопросами интересуются.
Почему это? Оператор "?" (вызов метода, если не null) в Котлине есть. Инфиксные методы есть. Что ещё нужно для счастья?

C>>Я не против хорошо сделанного языка
K>Никто не против хорошо сделанных языков, вот только встречаются хорошо сделанные языки чуть чаще, чем никогда.
Ну да. Есть Haskell, который идеальный. Но только на нём никто не пишет.

C>>со специальными случаями.
K>Вопрос в том, где остановится со всем этим ползучим частнослученизмом. А то умножать, например, целые числа оператором *, а числа с плавающей точкой — PLEASE MULTIPLY удовольствие сомнительное.
Не так. Если PLEASE MULTIPLY нужно будет использовать для седнионов, но для всех остальных будет "*" — тогда всё ОК. А именно в таком русле, видимо, Котлин и развивается.

Здравствуйте, Cyberax, Вы писали:

C>Почему это? Оператор "?" (вызов метода, если не null) в Котлине есть. Инфиксные методы есть.

А, т.е. это был пример кода на Котлине, а не некий псевдокод с гипотетическим решением проблемы?

C>Что ещё нужно для счастья?

Много чего.

K>>Никто не против хорошо сделанных языков, вот только встречаются хорошо сделанные языки чуть чаще, чем никогда.
C>Ну да. Есть Haskell, который идеальный.

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

C>Но только на нём никто не пишет.

Ну почему же никто? Пишут и намного больше, чем на Котлин.

C>Не так. Если PLEASE MULTIPLY нужно будет использовать для седнионов, но для всех остальных будет "*" — тогда всё ОК. А именно в таком русле, видимо, Котлин и развивается.

Мы вроде-бы только что выяснили, что Котлин предоставляет решение вроде * не для всех остальных, а только для одного единственного случая. Не для такого экзотического, как седнионы, конечно, но, скажем, такого как кватернионы. Для всех остальных будут вариации PLEASE MULTIPLY.

Здравствуйте, Klapaucius, Вы писали:

C>>Почему это? Оператор "?" (вызов метода, если не null) в Котлине есть. Инфиксные методы есть.
K>А, т.е. это был пример кода на Котлине, а не некий псевдокод с гипотетическим решением проблемы?
Я не уверен насчёт возможность определить оператор "+?" (т.е. возможно придётся использовать plus?), но оператор "?" точно в документации есть.

C>>Не так. Если PLEASE MULTIPLY нужно будет использовать для седнионов, но для всех остальных будет "*" — тогда всё ОК. А именно в таком русле, видимо, Котлин и развивается.
K>Мы вроде-бы только что выяснили, что Котлин предоставляет решение вроде * не для всех остальных, а только для одного единственного случая. Не для такого экзотического, как седнионы, конечно, но, скажем, такого как кватернионы. Для всех остальных будут вариации PLEASE MULTIPLY.
Пока что я вижу, что большинство моих личных потребностей Котлин, кажется, решает. И это мне нравится, даже если они реализованы как специальные случаи.

Мне не особо интересно, чтобы язык был полностью вытекающим из общего механизма без всяких исключений. А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.

Здравствуйте, Cyberax, Вы писали:

K>>А, т.е. это был пример кода на Котлине, а не некий псевдокод с гипотетическим решением проблемы?
C>Я не уверен насчёт возможность определить оператор "+?" (т.е. возможно придётся использовать plus?),

Проблема-то в том, что нужно специальный оператор определять, а нужна возможность обходиться импеющимся.

C>но оператор "?" точно в документации есть.

Да, я видел.

C>Пока что я вижу, что большинство моих личных потребностей Котлин, кажется, решает. И это мне нравится, даже если они реализованы как специальные случаи.

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

C>Мне не особо интересно, чтобы язык был полностью вытекающим из общего механизма без всяких исключений.

А этого и не нужно. Нужна возможность называть одинаковые вещи одинаково, а разные — по-разному.

C>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.

Ну, допустим, пугают — так тут и без макросов можно обойтись.

Здравствуйте, Klapaucius, Вы писали:

K>>>А, т.е. это был пример кода на Котлине, а не некий псевдокод с гипотетическим решением проблемы?
C>>Я не уверен насчёт возможность определить оператор "+?" (т.е. возможно придётся использовать plus?),
K>Проблема-то в том, что нужно специальный оператор определять, а нужна возможность обходиться импеющимся.
Ну вмонтируют его в стандартную библиотеку. И что?

C>>Пока что я вижу, что большинство моих личных потребностей Котлин, кажется, решает. И это мне нравится, даже если они реализованы как специальные случаи.
K>Ну, потребности-то зависят и от информированности в том числе. К примеру, когда ицелоп по ночам бьет — это интуитивно понятный недостаток. А то что радоваться нужно в наморднике — как недостаток может и не осознаваться. Ну привык человек к наморднику, а без намордника людей не видел.
Мы академий не кончали, и всё пишем на каких-то мэйнстримовых языках. Как-то: C++, Java, Scala, Erlang и прочих Питонах. Т.е. мои личные нужды примерно я себе представляю.

Я понимаю, что в обобщённом макроязыке можно будет делать всё что угодно, но лично мне это не особо интересно.

C>>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.
K>Ну, допустим, пугают — так тут и без макросов можно обойтись.
Как именно?

Здравствуйте, Cyberax, Вы писали:

C>>>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.
K>>Ну, допустим, пугают — так тут и без макросов можно обойтись.
C>Как именно?

Монадами, например. Когда Klapaucius говорил "лифтить", он имел в виду "поднимать в монаду".

VladD2,

LCR>>Самый продвинутый известный мне вариант описан в статье CZ:MultipleInheritance Without Diamonds — а именно ввести 2 вида отношений: extends и requires, и разделить понятия subtype и subclass.
LCR>>Вкратце, любые ромбы запрещены, но чтобы сохранить выразительность и переиспользовать функционал, можно ввести отношение requires: C requires A. Означает это, что C становится абстрактным, будет подтипом A (то есть можно приводить ссылки), и конкретные наследники C должны будут также наследовать и от A.

VD>Почитал (бегло). Сдается мне, что описанное по ссылке решение и то что предлагают ДжетБрэйновцы, если не одно и то же, то очень близкие решения.

Всё же не одно и то же. В Котлине не разделено отношение между классами на subtyping и subclassing и наследоваться можно без ограничений. В статье если A requires B, то наследуясь от A ты должен наследоваться и от B, иначе ошибка компиляции.

Впрочем, черканул им. Подождём ответа.

Здравствуйте, Cyberax, Вы писали:

C>>>Я не уверен насчёт возможность определить оператор "+?" (т.е. возможно придётся использовать plus?),
K>>Проблема-то в том, что нужно специальный оператор определять, а нужна возможность обходиться импеющимся.
C>Ну вмонтируют его в стандартную библиотеку. И что?

Да в какую стандартную библиотеку-то? Вы пишете, что использовать готовый оператор (в данном случае +) нельзя, надо будет определять другой.

C>Мы академий не кончали

Ну начинается...

C>всё пишем на каких-то мэйнстримовых языках
C>Scala, Erlang

Вот уж мейнстрим так мейнстрим.

C>Т.е. мои личные нужды примерно я себе представляю.

Писать на каждый чих (x!=null && y!=null) ? : null ? Ну и потребности у вас!

C>Я понимаю, что в обобщённом макроязыке можно будет делать всё что угодно, но лично мне это не особо интересно.

Да не надо делать все что угодно, надо делать все что удобно. Ну, допустим, вам удобство написания программ не особо интересно — вы программисту деньги платите а он пусть изворачивается как хочет, но мне непонятна мотивация авторов Котлина — они хотят сделать язык, на котором им будет удобно писать IDEA, но делают они неудобно сами же для себя. Им что, при написании IDEA методы с параметрами не нужно будет вызывать?

C>>>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.

Да, и кстати, разработчики языка-то кого боятся? Самих себя? IDEA Джамшуты разве пишут?

K>>Ну, допустим, пугают — так тут и без макросов можно обойтись.
C>Как именно?

Да обычными option и синтаксическим сахаром для любых монад/аппликативных функторов. С idiom brackets например, это будет выглядеть как-то так: z = (| x + y |)

Cyberax,

LCR>>Diamond-проблему как раз трейты решают, и это решение модульное, типобезопасное и непротиворечивое (см. статью Scalable component abstractions). Соглашусь, что несколько громоздкое из-за правил линеаризации. И ограничения есть — нетривиальные конструкторы недопустимы. Впрочем, если мы хотим позволить себе конструкторы с параметрами, тогда придётся навернуть систему типов и отношений между классами.
C>Вот только оно неудобное. Конструкторы реально достают, к примеру.

Как говаривал Нильс Бор, "Да, согласен, моя теория безнадёжно плохая. Предложите лучше."

На данный момент ввести конструкторы для трейтов (с разрешением вызова в порядке аналогичном линеаризации — это уже неоднократно предлагалось) означало бы поставить крест на дальнейшем развитии. Кто знает, может быть кому-нибудь из команды разработчиков придёт мысль обобщить отношение extends или with так, что проблемы с инициализацией уйдут в небытие По крайней мере, сейчас есть 3.5 известных мне способа обойти проблему с конструкторами в трейтах — можно подобрать подходящий.
(Вон в джаве сплошь и рядом лепят метод initialize, и ничего, считают это паттерном даже...)

C>Diamond-проблема на практике во многом надумана, она встречается раз в пятилетку. Поэтому стоит ввести какое-то поведение для неё, но не трогать самые частые случаи использования наследования — частичные mixin'ы.

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

На самом деле каждый из нас чуть ли не ежедневно сталкивается с последствиями неудовлетворительного решения Diamond-проблемы:

1. Существование интерфейсов как сущности — нафиг бы они сдались, если бы можно было оставить полноценные классы

2. Постоянно встречающийся совершенно дурацкий паттерн MyInterface <- MyInterfaceImpl, с единственной (!) реализацией. А почему нельзя просто использовать класс MyInterfaceImpl? Ну конечно, вдруг получится, что надо наследовать от чего-то ещё и от MyInterfaceImpl, и мы окажемся в неудобном положении тогда.

3. Якобы best practice "никогда не наследуйте реализацию, используйте делегирование". Ребята, а в чём проблема-то, если можно всегда отпочковать наследника, подмешать нужный функционал из других классов, переопределить что надо и вперёд? Увы, с интерфейсами и одиночным наследованием такой фокус не провернёшь, вот и вылезла "бест практика".

4. Ну и просто сплошь и рядом дубликаты одного и того же кода — просто потому что некуда или нельзя выделить повторяющийся функционал.

Дискасс, или всё и так очевидно?

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

C>>Diamond-проблема на практике во многом надумана, она встречается раз в пятилетку. Поэтому стоит ввести какое-то поведение для неё, но не трогать самые частые случаи использования наследования — частичные mixin'ы.
LCR>Я бы сказал несколько иначе: мы научились жить в кандалах, однако раз в пятилетку очередная примерка новых кандалов вдруг переполняет чашу терпения.
Нет, сложный diamond, как и глубокие иерархии классов вообще, реально не нужны.

LCR>На самом деле каждый из нас чуть ли не ежедневно сталкивается с последствиями неудовлетворительного решения Diamond-проблемы:
LCR>1. Существование интерфейсов как сущности — нафиг бы они сдались, если бы можно было оставить полноценные классы
Обычно интерфейсы сравнительно небольшие по объёму, что не создаёт проблем с их полной реализацией.

LCR>2. Постоянно встречающийся совершенно дурацкий паттерн MyInterface <- MyInterfaceImpl, с единственной (!) реализацией. А почему нельзя просто использовать класс MyInterfaceImpl?
Вообще-то, описанное тобой — это антипаттерн. Если есть только одна реализация, то она просто и используется. При необходимости делается рефакторинг.

LCR>Ну конечно, вдруг получится, что надо наследовать от чего-то ещё и от MyInterfaceImpl, и мы окажемся в неудобном положении тогда.
А не надо так делать.

LCR>3. Якобы best practice "никогда не наследуйте реализацию, используйте делегирование". Ребята, а в чём проблема-то, если можно всегда отпочковать наследника, подмешать нужный функционал из других классов, переопределить что надо и вперёд? Увы, с интерфейсами и одиночным наследованием такой фокус не провернёшь, вот и вылезла "бест практика".
При том, что имеем сильное связывание между классами. Реально сильное — и очень часто в предке начинает появляться код, специально заточенный на наследников.

LCR>4. Ну и просто сплошь и рядом дубликаты одного и того же кода — просто потому что некуда или нельзя выделить повторяющийся функционал.
LCR>Дискасс, или всё и так очевидно?
Вот это и есть единственный плюс от MH — немного сократить дублирующийся тупой код.

Здравствуйте, Klapaucius, Вы писали:

K>>>Проблема-то в том, что нужно специальный оператор определять, а нужна возможность обходиться импеющимся.
C>>Ну вмонтируют его в стандартную библиотеку. И что?
K>Да в какую стандартную библиотеку-то? Вы пишете, что использовать готовый оператор (в данном случае +) нельзя, надо будет определять другой.
Естественно, для оператора "+" не определено поведение с nullable-аргументом.

C>>Т.е. мои личные нужды примерно я себе представляю.
K>Писать на каждый чих (x!=null && y!=null) ? : null ? Ну и потребности у вас!
Честно говоря, я не помню, чтобы у меня было много подобного кода. Оператор "?" вот сильно поможет.

C>>Я понимаю, что в обобщённом макроязыке можно будет делать всё что угодно, но лично мне это не особо интересно.
K>Да не надо делать все что угодно, надо делать все что удобно. Ну, допустим, вам удобство написания программ не особо интересно — вы программисту деньги платите а он пусть изворачивается как хочет, но мне непонятна мотивация авторов Котлина — они хотят сделать язык, на котором им будет удобно писать IDEA, но делают они неудобно сами же для себя. Им что, при написании IDEA методы с параметрами не нужно будет вызывать?
Нужно. Но так, чтобы в месте вызова менять поведение в зависимости от null-абельности аргумента — это вряд ли. Это уже плохой дизайн.

C>>>>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.
K>Да, и кстати, разработчики языка-то кого боятся? Самих себя? IDEA Джамшуты разве пишут?
В большой команде они всегда есть.

K>>>Ну, допустим, пугают — так тут и без макросов можно обойтись.
C>>Как именно?
K>Да обычными option и синтаксическим сахаром для любых монад/аппликативных функторов. С idiom brackets например, это будет выглядеть как-то так: z = (| x + y |)
Во-во. Прекрасная иллюстрация к тому, что Котлин делает правильный выбор.

Здравствуйте, Cyberax, Вы писали:

C>Естественно, для оператора "+" не определено поведение с nullable-аргументом.

Как же так? А почему для метода blahBlahBlah(this, x, y) при таком вот использовании maybenull?.blahBlahBlah(x, y) вдруг — рраз! — и определено такое поведение для первого аргумента, а для всех прочих аргументов вдруг не определено?

C>Честно говоря, я не помню, чтобы у меня было много подобного кода. Оператор "?" вот сильно поможет.

Если есть общая установка, что такой вот код — это нормально, аналогичный бессмысленный код других видов также будет присутствовать, как же иначе-то?

C>Нужно. Но так, чтобы в месте вызова менять поведение в зависимости от null-абельности аргумента — это вряд ли. Это уже плохой дизайн.

Ох, но вот они же уже это сделали, только для первого аргумента. Только что вам это нравилось — а сейчас, вдруг, это оказался плохой дизайн. Что-то вы в показаниях путаетесь.

K>>Да обычными option и синтаксическим сахаром для любых монад/аппликативных функторов. С idiom brackets например, это будет выглядеть как-то так: z = (| x + y |)
C>Во-во. Прекрасная иллюстрация к тому, что Котлин делает правильный выбор.

Котлин белает выбор между
z = (x!=null && y!=null) ? x + y : null
и
z = (| x + y |)
в пользу первого. Тут два варианта, либо у нас спор чисто терминологический и вы все это время употребляли слово "правильный" в том смысле в котором я употребляю слово "неправильный", либо вы сейчас начнете доказывать что бедным и больным быть лучше чем богатым и здоровым. Вы, конечно, можете попробовать, но, по моему скромному мнению, код говорит сам за себя.

Здравствуйте, Lazy Cjow Rhrr

А я вот считаю, что любой сабтайпинг и след. отношение наследования — это грабли. В принципе. И как грабли не перекрашивай — астролябии из них не получить.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>4. Ну и просто сплошь и рядом дубликаты одного и того же кода — просто потому что некуда или нельзя выделить повторяющийся функционал.

LCR>Дискасс, или всё и так очевидно?

Я бы с тобой согласился, если не одно но. Десять лет назад я писал на С++ и думал как ты. Последние 10 лет я пишу на языке с теми самыми интерфейсами (которые, все же нужны как удобная абстракция и для совместимости с КОМ) и без того самого МН.

И знаешь что? За все время МН мне захотелось попользовать только раза два.

Не так часто оно реально надо.

Когда я писал на С++, то использовал ATL. Вот там МН было (казалось?) кстати. Но когда я перешел на дотнет, то казалось, что КОМ можно делать в разы проще и для этого вовсе не нужно МН.

Вот здесь http://nemerle.org/wiki/Traits описано как реализовать Traits для Nemerle. Этой страничке уже 6 лет, но Traits так никто и не реализовал. Причем реализация довольно тривиальна. Как ты думаешь, почему ее никто так и не сделал? Правильно, потому что она, как и Неуловимый Джо, на фиг никому не нужна.

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