Size: a a a

Scala User Group

2020 August 08

GP

Grigory Pomadchin in Scala User Group
AAA AAA
а «ки́рки» кто-нибудь произносит?
нет, “sursee” [ˈsɜːrsiː] обычно произносится
источник

λ

λoλegΥch in Scala User Group
цирк
источник

GP

Grigory Pomadchin in Scala User Group
λoλegΥch
цирк
еще цирка
источник

AK

Aleksey Kislitsa in Scala User Group
Grigory Pomadchin
нет, “sursee” [ˈsɜːrsiː] обычно произносится
Сьорси, но там есть нюансы заимствования греческих и римских слов, то что из Рима сперли читают как Ц, то что из Греции через К
Соответственно подобное правило и в других языках
Цезарь но Кесарь, Цирцея но Кирка
источник

GP

Grigory Pomadchin in Scala User Group
Aleksey Kislitsa
Сьорси, но там есть нюансы заимствования греческих и римских слов, то что из Рима сперли читают как Ц, то что из Греции через К
Соответственно подобное правило и в других языках
Цезарь но Кесарь, Цирцея но Кирка
вопрос не в этом был; автор серсей зовет; кирку скажешь кому никто не поймет о чем речь
мы вот цирком тут зовем
источник

AK

Aleksey Kislitsa in Scala User Group
Однако есть исключения, если заимствование из средневековой латыни то там как бог на душу положит
источник

.

.tmp in Scala User Group
Я говорю сирке
источник

.

.tmp in Scala User Group
А вообще называть так либы - извращение, такое впечатление, что нормальные слова у авторов закончились
источник

.

.tmp in Scala User Group
Да хоть pahom можно назвать. Чтобы нормально читалось/произносилось
источник

λ

λoλdog in Scala User Group
Эм...
источник

AK

Aleksey Kislitsa in Scala User Group
Grigory Pomadchin
вопрос не в этом был; автор серсей зовет; кирку скажешь кому никто не поймет о чем речь
мы вот цирком тут зовем
Так потому что греческие мифы пришли в европейскую культуру из Римской
источник
2020 August 09

VE

Vasiliy Efimov in Scala User Group
AAA AAA
а «ки́рки» кто-нибудь произносит?
кирче
источник

AA

AAA AAA in Scala User Group
источник
2020 August 10

VS

Vladimir Sam in Scala User Group
Есть аргументы, почему не стоит в имплементации какого-то интерфейса делать
val getSomeUsers: F[List[User]]

вместо
def getSomeUsers: F[List[User]]

?
Или мб я ошибаюсь и именно так и стоит делать (типа метод все равно вызовут, а тут у нас и граф уже собран и инициализирован)
источник

λ

λoλcat in Scala User Group
Vladimir Sam
Есть аргументы, почему не стоит в имплементации какого-то интерфейса делать
val getSomeUsers: F[List[User]]

вместо
def getSomeUsers: F[List[User]]

?
Или мб я ошибаюсь и именно так и стоит делать (типа метод все равно вызовут, а тут у нас и граф уже собран и инициализирован)
В имплементации нужно
источник

SA

Sergey Alaev in Scala User Group
Vladimir Sam
Есть аргументы, почему не стоит в имплементации какого-то интерфейса делать
val getSomeUsers: F[List[User]]

вместо
def getSomeUsers: F[List[User]]

?
Или мб я ошибаюсь и именно так и стоит делать (типа метод все равно вызовут, а тут у нас и граф уже собран и инициализирован)
Два довода против:
- нарушение единообразия - если у метода есть аргументы, придется писать def
- порядок инициализации val
источник

VS

Vladimir Sam in Scala User Group
спасибо ❤️
источник

NV

Nikita Vilunov in Scala User Group
Sergey Alaev
Два довода против:
- нарушение единообразия - если у метода есть аргументы, придется писать def
- порядок инициализации val
Можно подробнее? Какие проблемы будут из-за нарушения единообразия и порядка инициализации?
источник

IA

Ivan Aristov in Scala User Group
Nikita Vilunov
Можно подробнее? Какие проблемы будут из-за нарушения единообразия и порядка инициализации?
Если у тебя абстрактный класс B, в котором выводятся val bar из абстрактных val foo, то рантайм отвалится (или наследоваться иначе надо - new A { val foo = 123 } extends B )
источник

λ

λoλcat in Scala User Group
Тут речь не про абстрактный класс, а про имплементацию (видимо, не абстрактную)
источник