GP
в энивалах очевидно нет
да наверн ошибку кидает что нельзя прайвит зисы в энивалах
Size: a a a
2020 January 10
GP
да логично; я думал вдруг игнорит модифаер
M
мы обсуждали, останется ли оно в байткоде
правильно. и одна сторона говорила именно о конверсии, в результате которой дальше гуляет экземпляр FooOps, а другая (ты) имел ввиду, что остается вызов шлакметода на исполнение, который чикается джитом на раз
Oℕ
поэтому мы возвращаемся к формулировке задачи, где на уровне синтаксиса у нас два списка параметров. которые нужно собрать в один
Oℕ
что было бы, (возможно) тривиально, если бы не учёт возможных кросс-ссылок тайп-параметров и шедовинг
AO
а о том, что вызов метода конверсии останется в байткоде
А, лол, я вот этого утверждения вообще не увидел
Oℕ
шедовинг нужно запретить так, как будто это один список тайп-параметров, кросс-ссылки возможно запретить так, как будто это два разных списка
AO
Кстати.
1. От чего не придумали еще какого-нибудь универсального способо инлайнить это хозяйство во время компиляции? Раз уж есть такие замечательные вещи, как better-monadic-for.
2. Почему сам скаловский компилятор не умеет инлайнить такое? Есть какие-то препятствия?
1. От чего не придумали еще какого-нибудь универсального способо инлайнить это хозяйство во время компиляции? Раз уж есть такие замечательные вещи, как better-monadic-for.
2. Почему сам скаловский компилятор не умеет инлайнить такое? Есть какие-то препятствия?
а зачем? это escape анализ жита отлично делает
Oℕ
получаем новый особый синтаксический механизм совмещения списков тайп-параметров, который нужно тщательно продумать, чтобы не получить чего, и потом реализовать
отсюда понятно, почему на первой стадии создатели решили просто забить
отсюда понятно, почему на первой стадии создатели решили просто забить
Oℕ
А, лол, я вот этого утверждения вообще не увидел
тогда на что ты среагировал здесь https://t.me/scala_ru/260245 ?
AO
тогда на что ты среагировал здесь https://t.me/scala_ru/260245 ?
На то что код в байткоде по сути не такой, там вызов apply как то вообще сбоку
Oℕ
На то что код в байткоде по сути не такой, там вызов apply как то вообще сбоку
apply?
AO
ну или конструктора, чего там
AO
меня тригернуло то как ты написал вызов метода
Oℕ
так, как оно и есть в скале2
implicit class
превращается в пару класс и метод - имплисит конверсию, этот метод я там и записал
implicit class
превращается в пару класс и метод - имплисит конверсию, этот метод я там и записал
M
что было бы, (возможно) тривиально, если бы не учёт возможных кросс-ссылок тайп-параметров и шедовинг
запретить использование типа implicit class FooOps, полностью сделать его сахаром и оставить только поведение гарантированного стирания, даже без добавления extends AnyVal . И все проблемы уйдут. Я не помню случая, когда там действительно где-то сам FooOps требовался
Oℕ
запретить использование типа implicit class FooOps, полностью сделать его сахаром и оставить только поведение гарантированного стирания, даже без добавления extends AnyVal . И все проблемы уйдут. Я не помню случая, когда там действительно где-то сам FooOps требовался
Ну тут вопрос не как вторую скалу залатать, а как новую скалу сделать, чтобы расширения некостыльно выглядели для нубасов
Oℕ
ЭниВал классы, как их не чини воспринимаются как костыль всеми, включая меня
M
сами энивалы да, вобще ни о чем
VS
написать ещё один гивен
Олег, а если так написать
given [A, B](self: NonEmptyList[A]) extended with { - оно работает, но корректно ли ?
given [A, B](self: NonEmptyList[A]) extended with { - оно работает, но корректно ли ?