Size: a a a

Scala User Group

2021 February 28

a

aλeχknvl in Scala User Group
композиция и перформанс - вещи ортогональные в скале
источник

Α

Αγβεκ in Scala User Group
aλeχknvl
я просто немного выпадаю с микро-оптимизаций в скале. недавно мне кто-то сказал, что opaque type плохой, т.к. надо писать ручками apply, а final case class плохой потому что боксит
это оптимизация ради оптимизаций
источник

a

aλeχknvl in Scala User Group
можно либо одну, либо другую
источник

Α

Αγβεκ in Scala User Group
aλeχknvl
я просто немного выпадаю с микро-оптимизаций в скале. недавно мне кто-то сказал, что opaque type плохой, т.к. надо писать ручками apply, а final case class плохой потому что боксит
только если марсоходы писать
хотя там на си вроде пишут
источник

ΛВ

Λнтон Войцишевский... in Scala User Group
Αγβεκ
это оптимизация ради оптимизаций
а еще это иногда двойные стандарты и желание сделать «проще»
источник

Oℕ

Oleg ℕizhnik in Scala User Group
aλeχknvl
я просто немного выпадаю с микро-оптимизаций в скале. недавно мне кто-то сказал, что opaque type плохой, т.к. надо писать ручками apply, а final case class плохой потому что боксит
ну я не говорил, что это оптимизация, я просто отвечал на вопрос, почему в компайл и рантайме как минимум не хуже, чем кайнд прожектор и ручной нью, т.е. даже если не думать про оптимизации всё равно этот подход удобнее
источник

a

aλeχknvl in Scala User Group
это да, если вывод типов не ломается, то может удобнее
источник

a

aλeχknvl in Scala User Group
мой оригинальный FuncK.applyAnyVal и т.д.) ломал вывод типов иногда
источник

Α

Αγβεκ in Scala User Group
Oleg ℕizhnik
ну я не говорил, что это оптимизация, я просто отвечал на вопрос, почему в компайл и рантайме как минимум не хуже, чем кайнд прожектор и ручной нью, т.е. даже если не думать про оптимизации всё равно этот подход удобнее
код стал проще
ради этого можно и пожертвовать скорость
но если еще и код стал быстрее
тут скорее акцент в том что конструкция даже проще
а то что они быстрее на наносекунду это второстепенное
источник

Oℕ

Oleg ℕizhnik in Scala User Group
я оч надеюсь, что в скала3 упростят-таки синтаксис
источник

Oℕ

Oleg ℕizhnik in Scala User Group
добавят немного вывода
источник

a

aλeχknvl in Scala User Group
@specialized надо в скала3, а его все еще нет
источник

NV

Nikita Vilunov in Scala User Group
Oleg ℕizhnik
ну я не говорил, что это оптимизация, я просто отвечал на вопрос, почему в компайл и рантайме как минимум не хуже, чем кайнд прожектор и ручной нью, т.е. даже если не думать про оптимизации всё равно этот подход удобнее
funK компилится в SAM?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Nikita Vilunov
funK компилится в SAM?
funK просто возвращает свой аргумент, а вот та лямбда, что вы внутри пишете - да, это SAM лямбда
источник

Oℕ

Oleg ℕizhnik in Scala User Group
aλeχknvl
@specialized надо в скала3, а его все еще нет
кстати полифункции сразу специализированные
источник

ΛВ

Λнтон Войцишевский... in Scala User Group
Oleg ℕizhnik
добавят немного вывода
где-то в доке дотти или в ПРах видел маленькую строчку, что инференс в тайп-лямбдах и полиморфных функциях вообще не приоритетная задача и не будут трогать это в ближайшее время(
источник

Oℕ

Oleg ℕizhnik in Scala User Group
там сейчас генерируется класс с несколькими специализированными apply по-моему
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Λнтон Войцишевский
где-то в доке дотти или в ПРах видел маленькую строчку, что инференс в тайп-лямбдах и полиморфных функциях вообще не приоритетная задача и не будут трогать это в ближайшее время(
ну был не приоритетным, они даже в доки его не добавляли
источник

Oℕ

Oleg ℕizhnik in Scala User Group
теперь добавили
источник

Oℕ

Oleg ℕizhnik in Scala User Group
с позапрошлой версии
источник